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 <j...@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 <woh...@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/ >
