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" <rnew...@apache.org> > To: "CouchDB PMC" <priv...@couchdb.apache.org> > Cc: "Joan Touzet" <woh...@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 <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/ > > > >
