Hindsight is Always 20/20
by Jono Bacon
There are very few people in the world who fully understand Open Source. Sure, you can understand it from a technical perspective, but the social threads that cascade through the thousands of sub-communities are intensely difficult to truly understand. Unravelling this social fabric requires a keen interest in people-watching; an art form in itself. The only way you can really understand the community is to be an active member of it. You need to hang out on IRC, subscribe to mailing lists, go to LUG meetings, run websites, hang around shops giving out Open Source CDs and generally badger people about why free software is a good thing. You don't have to be a software developer to do this, but you do need to be a part of the community.
Unfortunately, there are a lot of people out there who don't really get it. These hapless individuals will typically guffaw their way into contributing, with every good intention, but their fundamental misunderstanding about the community will be their failing. They will expect that the Open Source way of doing things can mimic the commercial development culture, they will think that an Open Source project will attract a flock of developers at the drop of a hat, and they will also expect all good discussions to result in real working software as opposed to a This project has made no releases conclusion.
To illustrate such misunderstandings, I have a case study. This is a prime example of somebody who had great intentions, but just didn't understand the community at the time. Unfortunately, this hapless fool was me.
Back in 1999 I was 19 and about to go off to University. When I was 18, my brother got me into Linux and I was instantly wooed by it. Fascinated by the concept of distributed, collaborative community, I set up Linux UK; one of the first UK websites dedicated to Linux. I worked hard setting it up and promoting it, dedicating hours to it every night, and it was doing rather well. As time went on, I was looking for the next challenge and back then, KDE was rocking my world - I wanted to contribute. As a 19 year old gangly youth who had a reasonable reading knowledge of software development but not much of a practical-in-the-trenches knowledge, I figured I could just set up a team and they would come. Hey, Matthias Ettrich set up KDE and they came, Miguel de Icaza set up GNOME and they came, Linus Torvalds set up Linux and they came. I was certainly not expecting projects the size and esteem as those, but I figured it would be cool to run a software development team creating KDE software. What a clueless muppet I was...
So, I loaded up my trusty Usenet client and fired off this rather embarrassing collection of witterings to comp.windows.x.kde. This post demonstrates a clear misunderstanding of Open Source software development, from somebody who was genuinely convinced he knew it and could contribute in a pragmatic way. The intentions were innocent and certainly not driven by ego, but the expectation that I could just form a development team and tell them what to do was ridiculous.
One problem with my post back then is that I was laying out a list of requirements and expecting adherence from people who threw together code in their spare time for fun. Paragraphs such as "Programmers will need to have experience coding in C++ and preferably CORBA, and be able to code the Qt widget set. Experience at coding KDE applications is neccessery" are crazy. Aside from maybe spell-checking before I posted out such an important, ground shaking, everybody-must-see post that would attract an army of 'yes pick me!' contributors, it is is crazy to list job-like requirements when trying to attract people to a project.
The major problem with the post was that I was somehow expecting that people could be driven by a project management approach to Open Source software development. I remember thinking back then that it seemed crazy that the only way you can develop software is by coding a chunk of code and then encouraging others to join in. Surely this will only result in overly-complex unusable software? To be fair, this concern had reasonable merit - some of the software back then was awful when it came to usability, and I think my rather pathetic efforts to cobble together a team were a subconscious effort to contribute to the usability of software. Back then I remember looking at some of the GUI desktop applications and identifying what seemed like clear usability flaws. Although the intention was reasonable, my solution and subsequent cringe-worthy post demonstrated a mis-understanding of Open Source development.
The major lesson to learn from this post is the separation between what is theoretically possible and what is actually possible. Over the years I have seen so many people approach Open Source in a similar way - they think of something that could theoretically work, but in reality, the culture and climate of the community means that it just won't happen. When someone typically identifies 'theoretical possibility', this usually refers to something that is possible without any scientific, legal or financial restrictions. Running an Open Source development team is certainly not subject to these constraints, but it is subject to the hidden unwritten constraints of the community.
Hindsight is always 20/20
Since those days, I have made Open Source my ambition and my career and I have spent the last seven years exhaustively working to contribute to Open Source in different ways. I have been fortunate enough to be around great people who have contributed to my own development and understanding of the community and I am now confident enough to say that I believe I know the community and its constraints fairly well. Although it makes me cringe when I read that awful post, that post has itself been a useful learning curve in understanding the nuances of this social fabric that brings people together in the Open Source community.
I certainly don't profess to know everything about Open Source and its community, and I never will, but I am utterly convinced that the only way to understand the community is to become a part of it and build up a body of knowledge to compare which projects and ambitions work and which don't. When you can identify the hits from the misses, you can identify patterns in structure, and which factors made which effort a success. Aside from anything, it is always important to step back and identify where you missed the point, and I hope this rather embarrassing little tale will help to clarify some aspects of the community for others.
What do you think? Would you have joined my super elite team of KDE developers? Do you have any similar experiences/thoughts? Go on...share them with us...
anthropology dissertation about freedom in Debian
anthropology dissertation about freedom in Debian
Here are some interesting stats: