Re: Istio Steering Committee
+1 to messages that Kris and Josh have sent on this thread.
On Tue, Aug 25, 2020 at 12:04 PM, alexis richardson wrote: I am not familiar with specific concerns or complaints about Apache Kafka. But I have also not experienced how the project is operating from a first hand perspective. From a distance, it seems that the Apache Kafka PMC is welcoming to newcomers, and the work is done in the open. The committer roster, and the Project Management Committee, is made of individuals from many different backgrounds and employment sponsorship. The employer of the majority of committers and PMC members is on the record as being "committed to maintaining a good relationship with the Apache Software Foundation as well as the Apache Kafka community." [1] I definitely agree that there is much to learn (good and bad) from other projects, and welcome other perspectives on this. My intuition (biased by my limited sampling history, and various conversations) is that the ASF is going to _trust_ PMCs to operate in accordance with the philosophies and policies of the top level ASF. In those rare cases where concerns of undue commercial influence peculate up to the Board of Directors of the ASF (e.g., through the auditing process of quarterly reporting to the BOD), corrective actions are taken (like those in the frequently cited Apache Cassandra / DataStax event [2]). This thread is specifically about steering committees, and what they canI think it's good that you highlighted a *specific* concern about open-core feature withholding. Highlighting concerns can help focus a conversation toward how they can best be addressed. To me, it is not obvious that Steering Committees, Governing Boards, Advisory Boards, and Technical Oversight Committees are a good way to avoid the "slow walking" of capabilities that a vendor wants to hold as a proprietary capability. To me, much of what is generally desired is "insurance" that protects corporate interest in some piece of open-source software, and any valuable assets around it. It's not wrong to have corporate interests, or to seek conditions where corporate interests can be represented in a multi-stakeholder system. Personally, I find it easier to talk about them plainly and clinically. There is a lot of focus on having "a seat at the table" because you don't want another person to work against your interests. There's a lot less focus on what conversations are had and what decisions that are made around that table, and if the table is behind closed doors. I would like this to be better understood in across multiple communities and projects. My advice about open-core feature withholding is a pretty simple one: deliberations on how to best build software should be done in the public, in a way that puts the common good ahead of any particular company's priorities. Setting the culture, and expectations, should receive the most attention and continuous reinforcement. I think that signs point to Kubernetes getting that generally right: "Community over product or company" [3]. When making a deliberation about a feature or direction for the software, wear your "individual hat" most often, and if you find that you need to advocate on behalf of your employer, make it explicit by declaring that you're wearing employee-of-company hat. If we think that a committee or decision making board is required to make sound decisions that are free from conflicts of interest (like if a feature should be withheld because it is to the advantage / disadvantage of a particular company with a commercial interest in the software), I'd say that we need more attention on community building. Istio just launched a Steering Committee and that's why it is relevant.I think it is too soon to say much about this development. I've already made some less verbose views of mine (and mine alone) known on Twitter. Personally speaking, I think that the current seat allocation formula is problematic, as it can encourage gaming statistics. And that doesn't address a more fundamental question: what does a Steering Committee *do*, exactly? And why must it be done privately? Without getting a seat at the table, or at least being allowed in the room, you don't know. I think this all leads to conditions that weaken trust bonds through a sense of uneven power dynamics. And then everyone starts competing so they can be in The Room Where It Happens [4]. --msw (wearing his "individual" hat) [1] https://www.confluent.io/apache-guidelines/#the_importance [2] https://sdtimes.com/afs/apache-foundation-board-reining-datastax/ [3] https://github.com/kubernetes/community/blob/master/values.md#community-over-product-or-company [4] https://www.youtube.com/watch?v=WySzEXKUSZw
|
|