When Closed to Open Sucks
Sep 28, 2009 In Web Culture By Joshua AllenA recent presentation by Ian Bicking got me thinking about closed versus open source software. Does software transformed from closed to open source suck? How do Mix Online's products, which are designed to be open source from the very beginning, fit into the picture? Is it possible to make great closed to open source software?
Here's the quote from Ian's recent DjangoCon keynote (via Simon):
There was this clamour in the past to get companies to open source their products. This has stopped, because all the software that got open source sucked. It’s just not very interesting to have a closed source program get open sourced. It doesn’t help anyone, because the way closed source software is created in a very different way than open source software. The result is a software base that just does not engage people in a way to make it a valid piece of software for further development.
In one way, Ian is right: our team creates open source software differently than we would if we were targeting closed source. But does this mean transforming software from closed to open source is doomed to failure?
When Closed to Open Rules
I think that Ian may be overstating the case. We all can easily think of closed source projects which would make great open source projects.
Take 37signals Basecamp, for example. Although it is closed source, Basecamp's source likely meets or exceeds open source standards for code organization and quality. And community developers find projects like Basecamp engaging.
Another example is the engine that runs stackoverflow.com. Like Basecamp, stackoverflow has attracted open source clones, a good indicator that folks find it compelling.
When Closed to Open Sucks
On the flip side, many closed source projects fail as open source. For most, this is not simply because they were "created in a very different way", as Ian says above. Rather, many closed to open source projects fail because the software isn't even compelling to the people who created it.
We call these projects "abandonware". Abandonware happens when a company decides to open source a dead project because they don't feel like supporting it anymore. No wonder the community tends not to rally around these projects.
Really, if a software scenario isn't engaging enough to attract open source interest, it's probably not very interesting as closed source. And if the code isn't maintainable by the community, it's probably too expensive for your closed source programmers to maintain as well.
What Do You Think?
Why do people choose one model over the other, and does it really make a big difference? Does your team build or use open source software? Leave a comment below, or follow us on Twitter.
Follow the Conversation
9 Comments so far. You should leave one, too.
Opensourcing is a very “stylish” concept that may also [seem to] place code under more scrutiny than is placed upon the product of the code (the working software). It may discourage or delay updates due to the extra “dressing up” required or at least perceived for that scrutiny. The true goal of opensourcing should be, an OPEN request for, or at least “joyful” acceptance of, collaboration. Collaboration=engagement.
This is in stark contrast to what we’ve seen, just today (September 28, 2009) in GOOG’s C&D request against a user of GOOG’s “open-source” code. GOOG should NOT have offered “proprietary” code as “open-source” (in my opinion). This is blatant exhibitionism, rather than “opensourcing”. It is not a form intending to encourage human engagement (obviously: engagement yielded C&D!).
Engagement is what it’s all about. If the software will wither and die, due to lack of updates delayed by fear of scrutiny; or if the code should not be revealed, due to corporate exclusivity, then opensourcing is not the route to pursue!
Another problem is that organizations often fail to realize the challenge of running a successful open source project. In many cases, the time needed to organize developers, triage and assign bugs and maintain build quality is equal to or greater than a closed source project.
Just think about how much time it takes to organize a local team in the same office…
That being said, the time needed often decreases as the number of contributors grows because leaders within the community will often emerge. Just be prepared for some hard work in the early phases.
I don’t think its a black or white issue really, but I can say is that probably the biggest hurdles from going closed to open is building ‘hype’ over the project. Open source takes off when early adopters are excited about the project and its direction.
Oh and there is a difference between open-source and a company simply releasing its source.
I don’t think its a black or white issue really, but I can say is that probably the biggest hurdles from going closed to open is building ‘hype’ over the project. Open source takes off when early adopters are excited about the project and its direction.
Oh and there is a difference between open-source and a company simply releasing its source.
I’d agree with you, Salman, about the difference between open-source and a company simply releasing its source, but a company shouldn’t call it “open-source” as GOOG did, e.g. at http://source.android.com/ where they say, “Android is the first free, open source, and fully customizable mobile platform.”
If what CyanogenMod did doesn’t fall within the realm of “fully customizable” then I’m I’m afraid I don’t understand the meaning of “fully”
Does freedom suck?
Personally, I’m a fan of freedom…
@Pete – According to Ian, many projects that are in “captivity” tend to suck when then attain “freedom”. So maybe he’s saying that “liberation” sucks, even if freedom doesn’t. I tend to disagree anyway, based on the arguments above.
@fjpoblam – Looks like Cyanogenmod announced agreement with Google today. Situations like that suck, but I can understand why they happen with some frequency. The idea that open source is purely idealism is itself a sort of exhibitionism — companies always have ulterior business motives for doing open source. It’s when they get surprised and the idealism is forced to conflict with the business motives, that spats like that can happen.
@Ian, @Salman – Good points, and definitely matches my experience.
I developed a CMS for in-house use that we decided to open source because we were getting requests for it from a number of 3rd parties but didn’t want to get into selling and supporting it.
The problem was the effort required to re-factor, document and remove some domain specific things meant that it was never high priority so while it initially was welcomed folks found it to be quite a steep learning curve to adapt it and, with very few exceptions, we didn’t get any code checked back into the community.
I actually ended up working for one company who had taken the code, forked and significantly enhanced it and essentially built a large part of their business on it… but then run into a wall with some performance aspects (but by then they’d put so much of their own $ into it they didn’t want to share it with the community even if they would have got “free” support.
It’s not an easy path to tread.