+1 to both Shane and Myrle's input here. The Apache Way is all about consensus building in order to maximize the potential for collaboration between partners. It is impossible to drive consensus within a community of individuals without enabling them to be a part of the whole process. Large code drops equate to a statement of "this is the way it is - my way or the highway". It is not a model for consensus building.
However, there are other models in which vendors define direction. Shane refers to these as "maintainer led" but I think that is too general, I prefer the more specific vendor led, because it is possible to have a consensus driven maintainer led project. Vendor led and the Apache Way are different models. One scales the community very well (Apache Way) and is ideal for building frameworks and/or components from which products are built. The other (vendor led) doesn't scale so well but is ideal for building highly focused products. The Apache Way maximizes the opportunity for cross-organizational collaboration and thus drives combinatorial innovation. Vendor led limits the scope of the collaboration but allows one to target a more clearly defined customer base. The trick to success is ensuring that you are using the right model for the right parts of the open source ecosystem. There is no single model for governance of open source, success comes from understand when and how to apply different models to different parts of your software solution. Ross -----Original Message----- From: Shane Curcuru <a...@shanecurcuru.org> Sent: Thursday, October 18, 2018 8:26 PM To: Apache Community Development <dev@community.apache.org>; Apache Fineract Dev <d...@fineract.apache.org> Subject: Re: Why are large code drops damaging to a community? Myrle Krantz wrote on 10/18/18 7:18 AM: > Hey all, > > There are many forms of offlist development. One form of offlist > development is working on large code drops in private and then > contributing them all at once. Threshold size is probably arguable, > and varies by project; put that aside for the moment. I've been > working on an explanation of how large code drops damage community and > code. I'd love to hear your feedback. I'm including my project and > the dev@community list in the hopes that people from other projects > also have a perspective. Here it goes: Thanks Myrle for an excellent writeup, including details of how large code drops harm Apache style open communities. This is a great set of examples showing the "why" behind the ASF's requirement that the whole community be allowed to participate in *all* parts of a project's technical development. The requirement for an open and consensus-driven development process at the ASF doesn't just impact the individual perspective - which you've covered in detail in your post. More importantly, it impacts the whole *community* ownership feeling of an Apache project. This is a key difference I see between Apache projects and maintainer-led projects. There are many examples of maintainer projects with issues, successes, whatever. But they primarily focus on how a handful of maintainers are struggling to keep their project growing for the benefit of all their users. The issue is the mindset of "maintainers". An Apache project should have the entire community of contributors feeling like they have a stake in the project, that they can help build new ideas, and that they *share* as a whole group the direction of the project. While much of the actions are the same, my point is about the feeling of ownership. It's not just a few "maintainers" driving things; it's *everyone* who's a committer (and hopefully soon, many of the contributors who get voted in). Offlist development prevents this truly shared sense of ownership from developing, which is why it's prohibited for Apache projects. ...snip... > Open source projects require transparency, not just as a moral value, > but as a pragmatic prerequisite for collaboration. Offlist > development damages the community *and* the code. More to the point, repeated significant offlist development will attract the attention of the ASF board, which may well take direct action to prevent that kind of behavior from happening going forward. One advantage of the ASF's independent governance is that it can enforce the core open development model that's a key part of the Apache Way. Note that I'm struggling to find where "offlist development is forbidden" is explicitly called out on the apache.org website, so pointers to existing places that *explain* this core concept and why it's important are appreciated. My attempt to explain how open development works is here: http://shaneslides.com/apachecon/TheApacheWay-ApacheConNA2018.html#24 - Telegraph your intent: email dev@ with your *ideas* ahead of time. This allows feedback, encouragement, someone else to point out similar code is already over there, etc. - Draft designs openly. Put the rough first draft on the wiki/website/dev@ list, and then do your edits *in public*. This allows feedback on the architecture as it's being built, and again, gets better ideas. It also allows a sense of community ownership. - Submit work in chunks (add: on a regular and frequent basis). Checkin the shell of the API. Then checkin each section of implementation. If you're waiting for your code to look perfect before showing anyone else, you're not really helping the community. Doing the development in the open allows for... you guessed it, feedback. - Welcome feedback along the way. This doesn't mean you need to accept every change request or suggestion. But it does mean you can take the best ideas from the whole community to add them easily, as the individual bits of work are being done. -- - Shane ComDev PMC The Apache Software Foundation --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
