+1
>
> On October 19, 2018 at 4:18 AM r...@gardler.org wrote:
>
> +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
>
