Keith over at dotnetpimps (see trackback) has written a decent piece on the state of open source software and what it has and what it doesn’t. Really not anything that hasn’t been said before, but nicely summed up.
I’ve had discussions with mark on this topic over years (and with keith occasionally) and Mark’s take (which keith hit too) is that many open source projects lack management. Keith says ‘specs’ which is partly true, but not necessarily the root cause in all cases. I’ll post here some sketchy thoughts on this… and will probably touch on this later again 
Heh… he actually hits a few nails on the head. I think more the point is that it’s not specifically that they lack a spec. Well, that’s part of it, but it’s a symptom, not the root, I think. The root is there’s not enough of a unified need in the community. The pain of not having easy shared calendars isn’t high enough for people to write something. To the extent that things are written, the pain of them not being interoperable isn’t high enough to do anything about it.
The pain of having potentially having different web browsers to talk to different web servers was enough to coalesce people around the idea of embracing commong HTTP specs.
For example, If the google calendar proves extensible enough, there will be migration to using that as a standard to build other interfaces around. However, the need for most people to have ‘shared calendars’ isn’t that high outside of businesses. And because something’s already written/existing in many businesses (exchange/outlook) the water of software development efforts flows downhill to other cracks in the people’s needs. Does that make sense?
I saw one other thing Keith posted which is correct, but yet wrong (or too narrow)…
I’ve said this over and over again when I taught Linux certification classes at the college level.
“The open source community is great at building things based on a protocol or an RFC. If you don’t give them a spec, you never know what you’ll get.”
That’s a bold statement I know, but allow me to give a few samples. The main reason this occurs is the developers don’t have to think about what they are building.
Replace “open source community” with “software developers” and you’re correct. Name me one set of software developers in the non “open source” arena which have developed great projects/products without a spec. Not sure you can do it.
At the heart of this whole idea is that ‘open source’ is essentially just a process or philosophy behind building software. The primary tenents are that the software development should be open for review, possibly collaborative, open to contributions, and some other related concepts. There’s nothing in ‘open source’ development which precludes developing project requirements, gathering user feedback, addressing specific business needs, etc. It’s just that the overwhelming majority of ‘open source’ projects are done at a very small scale – tens of thousands of small one-off projects on sourceforge, for example, attest to that fact. As mentioned, MySQL and Apple are two examples of companies harnessing the positive aspects of open source – transparency, bug reporting, testing, user contributions (whether code or feedback/ideas), increased user base due to lower costs (in mysql’s case anyway!), and combining those positive effects with specific business requirements into a full business model.
There’s no need to be so harsh specifically on ‘open source’. Plenty of ‘closed source’ software companies have failed and will continue to do so for years to come, because the failure has little to do with open v closed and how well you can )or can’t!) run a business (and Keith knows I know this first hand!)
