couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: [DISCUSS] Proposed Bylaws changes
Date Thu, 14 Feb 2019 21:26:31 GMT
I am +1 on the RFC’s and -1 on the "not directly affiliated with the proposer's employer”


> On 13 Feb 2019, at 11:13, Jan Lehnardt <> 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 <> 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:
>> Quick summary:
>> * Added the RFC proposal process
>>   * The RFC will become an official template as part of this
>>   * 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:

View raw message