So who gets the best deal in the Open Source world?
As a consumer, I get free software. I can even get support (for a price). Good deal.
As a project leader, I’m the boss. Benevolent dictator. What’s not to like?
But what about the humble contributor?
I’ve dipped my toe into the open source waters a few times over the years, and it’s surprisingly hard to contribute. Now, I want to stress that this isn’t anything to do with the projects or the people involved – I’ve nothing but praise and admiration for all of them. Love you guys.
These are the problems that I see facing you:
1. Understanding the codebase. I downloaded the X Window System source once. And Firefox. Big mistake. Couldn’t understand a thing. There was just too much code. To set some kind of perspective, the current Chrome source requires 1.6 GB of hard drive space. The investment required to learn such a system well enough to fix a bug or implement a new feature is just huge.
Yeah, I know, I've picked the world’s largest OSS projects, but it should be recognised that there is a cost to not just learning the what and how of a codebase but also the why. It’s easier to change some change, it’s harder to change the right code.
2. Going dark. Jeff Atwood has already written about “going dark” – suddenly bounding up to an Open Source project with a massive code change that implements some huge feature or other. The trouble is, it’s very, very easy to go dark on an Open Source project.
I’ve done it. This blog has, for the last couple of years, run on a bit of software called Single User Blog. It was open source, I got a copy and used it to learn asp.net. And I made so many changes I ended up with a totally divergent codebase. Most of the changes I made didn’t get contributed back.
The trouble is, as a first time contributor, the desire is to contribute something worthwhile – which means a completed feature, not a string of small refactorings.
There’s an obvious solution here – communication. Talk to the project team, raise the issue, propose a solution, work on the implementation. Which leads us to…
3. It’s not your project. Perhaps the project team doesn’t want your feature or wants to implement it differently. You’re at the mercy of someone else.
I recently submitted a patch to Ayende’s AutoMockingContainer. It took over a month before it was applied (again, this is certainly not a comment against Ayende – the man’s a legend). It’s just not your project.
And this one is also a downside to using Open Source software in a commercial environment. At my last place of work, we implemented a WS-* based security architecture in Java. We wanted to use one of the various Open Source libraries out there, but none of them fitted our needs – they didn’t implement enough, and didn’t provide enough extensibility hooks.
We had to make significant changes.
And we had no guarantees that those changes would ever make it back into the project. That was quite a gamble – we had a highly customised version of an open source project. We could no longer take updates from their code, meaning we were now completely responsible for the entire codebase.
Options here are forking (and the cost of owning the new project), and, yes, communication.
(But communication can be too slow. In this instance, we didn’t have the time to develop a relationship, discuss a roadmap and submit anything other than an aforementioned code bomb. Is that a cop out?)
4. IP agreements. This is one I hadn’t thought of, but is, in hindsight, completely obvious and eminently sensible. How do I, as a project leader, know that the code submitted by Joe Random Programmer is theirs to contribute? That it wasn’t created on work time, with work resources? Or that it doesn’t contain some patented implementation? And once you do contribute, who owns the copyright to that code?
So, you have to sign some sort of agreement and return it to the project.
Sun requires it for OpenOffice:
Do I have to fill out a Sun Contributor Agreement?
Yes, if you intend to contribute source code or other materials which are intended to be compiled or otherwise integrated with the OpenOffice.org product, regardless of the size of the contribution (e.g., including contributions of 10 lines or less). However we encourage all contributors to the OpenOffice.org website domain, including the wiki, to fill out the SCA, as it streamlines the process for all.
“Including lines of 10 lines or less.” Phew.
Sun requires it, RedHat requires it, Mono requires it. Everyone should require it. Brad Wilson says of xUnit.net:
Yes, IP assignment agreements are strictly necessary. Any open source project without them is begging for future trouble.
All in, that’s quite a high barrier to entry (serendipitously, Jeff Atwood has just posted about OpenOffice’s high entrance fee).
If it’s so difficult then, should I contribute?
Of course.
You just have to be patient and communicate with the guys on the project.
Or start your own…