Agreed. Healthy projects (in the sense of thriving, growing, adapting to changing needs etc.) welcome outside input and take the effort to foster it. Clear communication and transparency helps a lot, because a frequent problem I’ve encountered (on both sides of the interaction) is that an eager outside contributor doesn’t quite understand the ‘gestalt’ of the project well enough, so ends up with suggestions or patches that don’t fit with the direction and goals of the project. Either similar ideas have already been discussed and rejected, or the new ideas are out of scope. (Real example: “Thanks for your input, but this is a graphics rendering engine, not a game development kit, so your patch to include sound library x is out of scope. Please feel free to include this engine in your own GDK project – we love to see our work serve a useful purpose.”) After a time, explaining things again and again gets exhausting, which is probably one reason groups gravitate toward elite isolationism if not careful. Never underestimate the power of a well placed FAQ (heh).

The Gentoo leadership should exist, and should organize as subprojects. This is already done, in the form of Gentoo herds. Yes, the leadership should consist of proven programmers and leaders; however they should not ignore the individual coder.

As for the statement that the one-off programmer has an obligation to contribute, that’s a reversal of what I said. I feel that the project has an obligation to listen to its users, the same as any project, whether FLOSS or commercial. In the case of FLOSS, there is the advantage that the user may be a programmer; instead of contacting support with a problem, this one-off programmer can instead contact with a solution.

The best, most successful, long-lived FLOSS projects are the ones that have clear purpose, goals and leadership (whether an individual or cooperating group). Casual participation isn’t really possible if a project never reaches a viable stage of development, and this is made possible by the very things Donnie discusses (amonst other things).

I’ll finish with a reminder that the appeal of FLOSS in the early days wasn’t necessarily the opportunity to participate in large and complex voluntary efforts, at least not entirely. It was that a useful piece of software created by another group with expertise and deep interest in that software could be easily modified to suit the needs of a particular “user” (where user could mean an individual, group or organization). And further that these useful modifications could be shared with others without penalty or consequence (and should be). That includes the original upstream project if they are interested, but that’s not obligatory. Equally valid is a fork if that suits the situation better. So the idea that a casual, one-off programmer has an obligation to contribute to the parent project in order to have it be viable and meet some vague definition of “bazaar-style open source development” is new to me. Under the GPL, at least, the obligation is only to share the modifications if the software is distributed to anyone. The rest is more about good manners and an acknowledgement that disorganized anarchy is less desirable than a central focal point as a means to ensure that useful software has a long useful lifetime.

It’s possible that I’ve misread your entry; however when you say “The core of these ideas is creating a development community composed only of top-notch contributors and putting the entire Gentoo project into a cycle of continuous improvement, from the bottom up.”, it indicates to me that you want only this top-notch development community involved, while blocking any others.

Personally, I feel that bazaar-style open source requires the contributions of casual, one-off programmers. They may only have a single patch to contribute to the entire distribution, but that contribution is still valuable.

As I understand it, this is your contention: Adding any level of selectivity or standards of behavior or action to a community transforms it into a cathedral.

In fact, I see it as a bazaar. Even at a bazaar, you have to obey the laws. You can’t expect to act however you like without consequences.

I re-read ESR’s paper, and this is a useful quote:

“There is another kind of skill not normally associated with software development which I think is as important as design cleverness to bazaar projects—and it may be more important. A bazaar project coordinator or leader must have good people and communications skills.

This should be obvious. In order to build a development community, you need to attract people, interest them in what you’re doing, and keep them happy about the amount of work they’re doing. Technical sizzle will go a long way towards accomplishing this, but it’s far from the whole story. The personality you project matters, too.”

Not only do you have to keep them happy about the amount of work they’re doing, you need to be happy about the direction of the project and be happy yourself about their contributions.

One other quote from that essay:

“Can we save defining goals as a justification for the overhead of conventional software project management? Perhaps; but to do so, we’ll need good reason to believe that management committees and corporate roadmaps are more successful at defining worthy and widely shared goals than the project leaders and tribal elders who fill the analogous role in the open-source world.”

So you can see that he believes in the value of defining goals, and perhaps beyond that, takes it as assumed that having shared goals is a good idea. To me, it follows that coming up with ways of achieving those goals is a good idea.

One thing that ESR doesn’t touch on much at all in any of his essays is the idea of community. But numerous other people have written about the importance of creating and maintaining a good community. If you’ve got people who just aren’t any good, they demotivate the better ones, eventually to the point where your best contributors walk away.