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

Reply via email to