couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <rnew...@apache.org>
Subject Re: [DISCUSS] Proposed Bylaws changes
Date Thu, 14 Feb 2019 21:46:35 GMT
Hi,

Sure.

Any member of the PMC who is railroading changes through on behalf of their employer to the
detriment of this project should be disciplined, ultimately losing their PMC membership (and
their binding vote on future changes).

The "not directly affiliated with proposer's employer” seems to presume bad faith on the
part of some of those with binding votes at worst, and, at best, is stating that the PMC already
distrusts its members that happen to be employed by IBM. If that is currently the case, the
PMC should act directly and censure those members who have acted contrary to the requirements
of an ASF PMC member.

I don’t see how this piece is coupled with RFC, especially when writing RFC’s, and taking
them through a community review process, is likely to mitigate the issue of significant work
being designed in private but ultimately contributed to CouchDB publicly.

If the “RFC before code” approach does not work out, I will add my support to the affiliation
requirement, but with a heavy heart. To presume such bad faith within the PMC, or to suspect
it so strongly as to embed pre-emptive measures into our bylaws, points at issues deeper than
a bylaw change can reasonably address. Other, stronger responses would seem more appropriate
should that come to pass.

B.

> On 14 Feb 2019, at 21:31, Joan Touzet <wohali@apache.org> wrote:
> 
> Hi Robert,
> 
> Care to give any more detail on your -1?
> 
> I gave a fairly extensive argument as to why I think such a
> safeguard is important for our community. I also feel it would
> be meaningless to push through an RFC without community support.
> But our current bylaws would make this very straightforward.
> Why not put in this "backstop?"
> 
> -Joan
> 
> ----- Original Message -----
>> From: "Robert Samuel Newson" <rnewson@apache.org>
>> To: "CouchDB PMC" <private@couchdb.apache.org>
>> Cc: "Joan Touzet" <wohali@apache.org>, "CouchDB Developers" <dev@couchdb.apache.org>
>> Sent: Thursday, February 14, 2019 4:26:31 PM
>> Subject: Re: [DISCUSS] Proposed Bylaws changes
>> 
>> I am +1 on the RFC’s and -1 on the "not directly affiliated with the
>> proposer's employer” item.
>> 
>> B.
>> 
>>> On 13 Feb 2019, at 11:13, Jan Lehnardt <jan@apache.org> wrote:
>>> 
>>> Sounds fantastic, thanks too for the additional context! I’d love
>>> for us to lead the way here (yet again).
>>> 
>>> Best
>>> Jan
>>> —
>>> 
>>>> On 12. Feb 2019, at 20:15, Joan Touzet <wohali@apache.org> wrote:
>>>> 
>>>> Hi everyone,
>>>> 
>>>> There appears to be general consensus on the RFC process, with no
>>>> objections to the proposal itself.
>>>> 
>>>> I'd like to propose the following changes to our bylaws:
>>>> 
>>>> https://github.com/apache/couchdb-www/commit/8ae3a5a230b1717d7affe23625eeb288635aa542
>>>> 
>>>> Quick summary:
>>>> 
>>>> * Added the RFC proposal process
>>>>  * The RFC will become an official template as part of this
>>>>  * https://github.com/apache/couchdb/pull/1914 adds Bob's request
>>>>    to include a Security section
>>>> 
>>>> * Proposed a new "qualified lazy majority" approval model for
>>>> RFCs:
>>>>  * Requires 3 binding +1 votes
>>>>  * Requires more binding +1 votes than binding -1 votes
>>>>  * (NEW) Requires at least +1 binding vote from an individual
>>>>    not directly affiliated with the proposer's employer (if
>>>>    applicable)
>>>> 
>>>> * Changed URLs to use the new Pony Mail web interface (yay!)
>>>> 
>>>> While today we are in a great situation where no single entity
>>>> dominates
>>>> CouchDB development (to the exclusion of others), I believe this
>>>> new
>>>> approval model (just for RFCs) will prevent that from occurring in
>>>> the
>>>> future, and will ease a long-standing concern I have held.
>>>> 
>>>> 
>>>> If there is no strong objection, I will start the VOTE later this
>>>> week.
>>>> As this is both creating and amending our official documents, the
>>>> vote
>>>> will be a lazy 2/3 majority vote, with binding votes only from PMC
>>>> members.
>>>> 
>>>> 
>>>> Why is this so important to me? Recently, on another ASF mailing
>>>> list,
>>>> there was a discussion about some of the changes happening in the
>>>> commercial world, and as it relates to big companies giving back
>>>> to open
>>>> source. (You may have read about some competing database projects
>>>> changing their license, for instance.)
>>>> 
>>>> Allen Wittenauer graciously allowed me to excerpt his post, which
>>>> is
>>>> critical of the Apache Hadoop community, and share it here as a
>>>> cautionary tale:
>>>> 
>>>>>>      This pretty much ignores the committer hoarding that is
>>>>>>      happening in a lot of ASF projects.  It’s something that
>>>>>>      Jeff
>>>>>>      hinted at in a previous reply that I think people
>>>>>>      completely
>>>>>>      missed:
>>>>>> 
>>>>>>> The obvious reality is that the companies who build service
>>>>>>> around
>>>>>>> "pay to call me when it breaks" are very, very often the same
>>>>>>> companies who hire all the committers, who fund all the dev,
>>>>>>> who end
>>>>>>> up in danger when a cloud provider offers their product as a
>>>>>>> service.
>>>>>> 
>>>>>>      Most of the Hadoop vendors tried to hire as many of the
>>>>>>      committers as they possibly could and was even part of
>>>>>>      some
>>>>>>      PR campaigns (“We have more!”  “Ours were first!”) 
This
>>>>>>      resulted in the community outside of those vendors being
>>>>>>      mostly ignored. This also built a feedback loop where PMC
>>>>>>      members promote their coworkers at a significantly higher
>>>>>>      rate than non-coworkers because the only contributions
>>>>>>      that
>>>>>>      were being looked at were the ones that helped their
>>>>>>      employers.  (Anecdotally, coworkers: committer in 6
>>>>>>      months,
>>>>>>      non-coworkers, ~1-2 years, if ever) As a result, the
>>>>>>      project
>>>>>>      is a shell of its former self since it was impossible for
>>>>>>      outsiders to make major, disruptive advancements in the
>>>>>>      project.  Worse yet, Hadoop is now overwhelmingly
>>>>>>      controlled
>>>>>>      by one company since two of those vendors were forced to
>>>>>>      merge.
>>>>> [snip]
>>>>>>      This is probably the key reason why a lot of companies
>>>>>>      participate in open source.  Maybe if companies didn’t
>>>>>>      feel
>>>>>>      the need to hire every single person they could get their
>>>>>>      hands on to try and control the project, maybe the cloud
>>>>>>      providers would be more willing to donate man power.  As
>>>>>>      it
>>>>>>      is, there is little point for anyone outside of a company
>>>>>>      whose mission is to be “the source” for their project
>>>>>>      (officially or unofficially) to contribute to non-diverse
>>>>>>      projects.
>>>> 
>>>> From my informal chats with people at ApacheCon 2018 in Montreal,
>>>> this
>>>> is a hot-button topic. I'd like to get CouchDB out from under this
>>>> cloud.
>>>> 
>>>> Again I am NOT ASSERTING that this is where we are today. I think
>>>> our
>>>> dev community works well together and is not controlled by a
>>>> single
>>>> entity. I just want to remove the possibility for this sort of
>>>> abuse to
>>>> occur, and I think that doing so thru the RFC process is the right
>>>> step
>>>> at this time.
>>>> 
>>>> It is in everyone's best interest that RFCs happen, that we have
>>>> consensus agreement on them, and that an open vote happens where
>>>> it's
>>>> clear that no single party is forcing through changes against the
>>>> will
>>>> of other committed parties.
>>>> 
>>>> -Joan
>>> 
>>> --
>>> Professional Support for Apache CouchDB:
>>> https://neighbourhood.ie/couchdb-support/
>>> 
>> 
>> 


Mime
View raw message