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
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.
> 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:
- 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.
The Apache Software Foundation