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.
Good feedback Mike. In regards to replacing “open source community” with “software developers” I think if you read my next sentence you’ll understand what I think of when I say “open source community”. Primarily I am refering to developers (as noted in the next sentence). There are people that may use open source software but in the context of the article I was talking about development in a broader sense.
And thanks for saying developers whether they are writing for either platform do not turn out great projects/products without a spec because that just further prooves my point because in a commercial setting there will be a spec to refer to 99.9% of the time.
Of course there isn’t anything that precludes a developer of an open source project to gather feedback or address specific business needs. The problem is it isn’t happening and never will because we are talking about left brain and right brain people that need to carry out certain tasks. If I can stereo type the typical developer for a moment (and you know that I know you’ve known people like this) imagine sending them out into the field to gather information and building a spec? They don’t even comment their code why should they build a spec? I mean honestly we are talking about the needs for two different types of people which is exactly why we have analyst or other people to do that leg work. And this doesn’t matter if we are talking about commercial software or an enterprise company writing software to make it’s business more efficient there is going to be a gathering phase before anything is written.
Maybe business analyst throughout the world should devote their time in gathering information from end user’s so the open source developer will know what to build? Are there any volunteers out there to give up endless hours of your free time in exchange for some open software that can be viewed by other developers? Or would you just rather spend your free time with your family at the lake and pay the $50.00 for the software at Circuit City? Or do you just want to let the developer figure it out on his own and create yet AWSFP (another worthless source forge project)?
because in a commercial setting there will be a spec to refer to 99.9% of the time.
I don’t think that’s true. Breaking this up, I see commercial settings as either being “Shrinkwrap or ASP software” (software sold for money) and “inhouse development for internal needs” (software supporting a business’ needs).
“Requirements” or “specs” are something that are sorely lacking in the majority of situations around the world. Your situation at QL might be slightly different, but you know/remember that most projects ‘fail’ (by whatever definition) not because a developer didn’t know how to write to a filesystem or similar stuff. It’s because the requirements weren’t fully understood or fleshed out. This happens equally in almost any situation – the only difference with many OS projects is that it’s usually just a few people who only have to answer to themselves, and can simply abandon a project when they no longer need it.
There certainly is a need to have business people contribute project management/requirements docs/etc to open source projects. Very few would take the input, as most of those communities tend to value ‘code’ solely to the exclusion of anything else. But looking at the success of Apple or even Tivo taking open source code/projects and making solid businesses around them, it seems that there’s still gold in them thar hills.
Would most people contribute to something that would only save them $50 – yeah, that doesn’t make much sense. SugarCRM seems to be a decent new poster child for the open source model – they’re creating enough value – potentially saving companies hundreds or thousands compared to salesforce.com (or maybe the MS CRM package), for example – that it’s worth it for some % of users to contribute back. They’re making enough $ to have business people manage that aspect, and they’re reaping some degree of feedback and goodwill by having the project be open source. Seemingly the best of all worlds, but it’s not a model that can necessarily work for all projects, if only because of the potential $ savings for businesses.