Are there restrictions on the suitability of open source methods? Are there kinds of software for which closed source development methods are inherently preferable and inherently more likely to succeed?
These questions are part of a recent discussion triggered by Nokia’s Ari Jaaksi’s posting “Different ways and paradigms” that looked for reasons why various open source software development methods might be applicable to some kinds of project, but not to others. As Ari asks,
“Why would somebody choose a specific box [set of methods] for their products?”
One respondent suggested that software with high security and high quality criteria should be developed using closed source methods rather than using open source.
Another stated that,
I firmly believe ‘closed’ source is best route for targeting consumers and gaining mass appeal/ acceptance.
That brings me back to the question I started with. Are there features of product development – perhaps involving security and robustness, or perhaps involving the kinds of usability that are important to mainstream consumers – to which open source methods aren’t suited?
Before answering that, I have a quick aside. I don’t believe that open source is ever a kind of magic dust that can transform a failing project into a successful project. Adopting open source, by itself, is never a guarantee of success. As Karl Fogel says in the very first sentence of Chapter 1 in his very fine book “Producing open source software: how to run a successful free software project“,
“Most free projects fail.”
Instead, you need to have other project fundamentals right, before open source is likely to work for you. (And as an aside to an aside, I believe that several of the current attempts to create mobile phone software systems using open source methods will fail.)
But the situation I’m talking about is when other project fundamentals are right. In that case, my question becomes:
Are there types of software for which an open source approach will be at odds with the other software disciplines and skills (eg security, robustness, usability…) that are required for success in that arena.
In one way, the answer is trivial. The example of Firefox resolves the debate (at least for some parameters). Firefox shows that open source methods can produce software that scores well on security, robustness, and usability.
But might Firefox be a kind of unusual exception – or (as one of the anonymous respondents to Ari Jaaksi’s blog put it) “an outlier?” Alternatively – as I myself believe – is Firefox an example of a new trend, rather than an irrelevant outlier to a more persistent trend?
Regarding usability, it’s undeniable that open source software methods grew up in environments in which developers didn’t put a high priority on ease-of-use by consumers. These developers were generally writing software for techies and other developers. So lots of open source software has indeed scored relatively poorly, historically, on usability.
But history needn’t determine the future. I’m impressed by the analysis in the fine paper “Usability and Open Source Software” by David M. Nichols and Michael B. Twidale. Here’s the abstract:
Open source communities have successfully developed many pieces of software although most computer users only use proprietary applications. The usability of open source software is often regarded as one reason for this limited distribution. In this paper we review the existing evidence of the usability of open source software and discuss how the characteristics of open-source development influence usability. We describe how existing human-computer interaction techniques can be used to leverage distributed networked communities, of developers and users, to address issues of usability.
Another very interesting paper, in similar vein, is “Why Free Software has poor usability, and how to improve it” by Matthew Paul Thomas. This paper lists no less than 15 features of open source culture which tend to adversely impact the usability of software created by that culture:
- Weak incentives for usability
- Few good designers
- Design suggestions often aren’t invited or welcomed
- Usability is hard to measure
- Coding before design
- Too many cooks
- Chasing tail-lights
- Scratching their own itch
- Leaving little things broken
- Placating people with options
- Fifteen pixels of fame
- Design is high-bandwidth, the Net is low-bandwidth
- Release early, release often, get stuck
- Mediocrity through modularity
- Gated development communities.
As Paul says, “That’s a long list of problems, but I think they’re all solvable”. I agree. The solutions Paul gives in his article are good starting points (and are already being adopted in some projects). In any case, many of the same problems impact closed-source development too.
In short, once usability issues are sufficiently understood by a group of developers (whether they are adopting open source or closed source methods), there’s no inherent reason why the software they create has to embody poor usability.
So much for usability. How about security? Here the situation may be a little more complex. The online book chapter “Is Open Source Good for Security?” by David Wheeler is one good starting point. Here’s the final sentence in that chapter:
…the effect on security of open source software is still a major debate in the security community, though a large number of prominent experts believe that it has great potential to be more secure
The complication is that, if you start out with software that is closed source, and then make it open source, you might get the worst of both worlds. Incidentally, that’s one reason why the source code in the Symbian Platform isn’t being open-sourced in its entirety, overnight, on the formation (subject to regulatory approval) of the Symbian Foundation. It will take some time (and the exercise of a lot of deep skill), before we can be sure we’re going to get the best of both worlds, rather than the worst of both worlds.
dw2 
I enjoyed this post, but I’m not sure it characterizes David Wheeler’s article accurately. Then again, Wheeler mischaracterizes his own article himself, in his closing lines, which you quoted:
“In short, the effect on security of open source software is still a major debate in the security community…”
But if you read the article, and the people it quotes, Wheeler is essentially answering the question with a “yes”: open source code is, in the long run, more secure. If there really is a debate about this within the security community, nothing Wheeler said or quoted demonstrates that. Instead, his article makes a compelling case that open source is simply more secure, but that open-sourcing formerly closed code may lead temporarily to more vulnerability for that code, and that many security experts agree about this.
I agree with you that he’s right. There’s no evidence that closed-source code is more secure than open source code, and plenty of evidence for the reverse (c.f. the voting machine controversies, ahem). At this point, we have enough history with the issue that I’d simply have to question someone’s credentials as a security “expert” if they were to claim that closed-source software is somehow structurally more secure. That would match neither logic nor experience.
It’s great that you’re doing a security review of Symbian code before open-sourcing it, though — that’s the best of all worlds, assuming that it does get opened up eventually.
Thanks, by the way, for your kind words about my book. The URL I usually use for it is producingoss.com, since the full text is available there under a free license.
Comment by Karl Fogel — 3 September 2008 @ 6:18 pm
I enjoyed this post, but I’m not sure it characterizes David Wheeler’s article accurately. Then again, Wheeler mischaracterizes his own article himself, in his closing lines, which you quoted:
“In short, the effect on security of open source software is still a major debate in the security community…”
But if you read the article, and the people it quotes, Wheeler is essentially answering the question with a “yes”: open source code is, in the long run, more secure. If there really is a debate about this within the security community, nothing Wheeler said or quoted demonstrates that. Instead, his article makes a compelling case that open source is simply more secure, but that open-sourcing formerly closed code may lead temporarily to more vulnerability for that code, and that many security experts agree about this.
I agree with you that he’s right. There’s no evidence that closed-source code is more secure than open source code, and plenty of evidence for the reverse (c.f. the voting machine controversies, ahem). At this point, we have enough history with the issue that I’d simply have to question someone’s credentials as a security “expert” if they were to claim that closed-source software is somehow structurally more secure. That would match neither logic nor experience.
It’s great that you’re doing a security review of Symbian code before open-sourcing it, though — that’s the best of all worlds, assuming that it does get opened up eventually.
Thanks, by the way, for your kind words about my book. The URL I usually use for it is producingoss.com, since the full text is available there under a free license.
Comment by Karl Fogel — 3 September 2008 @ 6:18 pm