A Little Neighborly Consideration, If You Please?

The other night a friend of mine, an active open source developer, told me something which has convinced me all the more that you can't be a good open source developer by simply being a good programmer. You have to also be a good neighbor, for lack of a better word.

(Note: For the sake of consideration for all involved, I'm sanitizing this anecdote quite heavily.)

My friend -- let's call him Barry -- is one of the developers of a certain open source communications product. It keeps his hands full. Not long ago, someone posted to the "users" mailing list for the product asking for help writing a project that amounted to a reinvention of the wheel. Worse, this other fellow didn't seem to realize that; from the way he talked about the project he had in mind, he sounded as if he was convinced developers and users alike would drop whatever they were doing and flock to him based on the concept alone.

Barry wrote to the guy offlist and did his best to explain to him that the way he was pitching this whole thing to people -- again, developers and users alike -- was not likely to win him any adherents. "You don't have a clear idea of what you want to do," Barry told him, "or, at the very least, you're not communicating it well. You're reinventing something that has been done many times before. You don't have a design for what you're doing, you can't give people a single solid reason why anyone should use your program once it's stable -- and what's more, you don't have any rep in the community as a developer."

The response Barry got amounted to "you should join our coding team". Barry wrote back politely asking that he not be contacted about this again in the future. So far he hasn't been, but the whole blighted experience squares with other things he's seen in the FOSS community, much to his chagrin.

Software is hard (Barry says). People who can and do make worthwhile contributions to open source projects are in heavy demand -- and, in turn, they become pretty demanding themselves. They can't afford to have time wasted -- any more than, say, a popular band looking for a replacement drummer right before going on tour can afford to waste time with some clown who thinks he's the next Keith Moon or Neil Peart.

But newcomers to FOSS have this conceit that software's actually pretty easy. All you need to do is come up with a great concept, dazzle some existing expert programmer with it, bring them on board, and presto! Instant FOSS success story. Except that a) the programmer is usually far better at figuring out how hard the task in question really is; b) they often already have a ton of things to do; and c) the person making the request typically comes out of the blue with no pedigree of their own work.

Barry's way of heading this kind of thing off pre-emptively is what he describes as a FOSS apprenticeship program. If someone wants to do this sort of work, then they can partner with an existing project that needs someone to do some basic work. There, they can cut their teeth, learn the protocol from the inside out, and build the contacts and reputation that will become useful later on. In short, first they need to get their FOSS legs, and then they can afford to dream big.

I like the idea for a bunch of reasons. It stands to make the FOSS world that much more open to those on the outside, and it also makes it clearer what will be required of people who want to dive in and start coding. And maybe it'll mean Barry won't have to endure another pitch from a bad neighbor who seems to think "open source" means "free coders for the taking".

Follow me and the rest of InformationWeek on Twitter.