Open Software Development Process

When you spend much of every day in front of a computer (which you probably do if you are reading this), you come to know the intricacies and quirks of your software much as a musician comes to know the feel of their favourite instrument. Sometimes the smallest bugs can become the biggest annoyance.

Internet Explorer is a program I use frequently. In general, it is a good program. However, it has quirks that drive me mad. Many of these quirks affect many users and could probably be fixed in a matter of hours. However, I don’t report these issues to Microsoft. Why is that?

I don’t think Microsoft will listen. I don’t think Microsoft is a bad company (you should be suspicious of anyone who claims it is). However, Microsoft is not a particularly open company, and they are enormous. Would my feature request or bug fix request ever get through to a person who would be able to evaluate it effectively? I doubt it. This isn’t necessarily Microsoft’s fault, though I’m sure they could improve both their responsiveness and my perception of their responsiveness. It may simply be that there are too many people like me with too much feedback to reasonably parse.

This is where smaller and more open software development processes can really shine. In the past few months, since Apple’s Safari web browser project was announced, there has been a lot of discussion and an enormous amount of feedback on the browser. I’m sure there was a lot of noise, but there has certainly been a lot of useful feedback.

Add to this an open and responsive developer, and things get interesting. David Hyatt was hired by Apple to work on the Safari project. He publishes a weblog on which he regularly posts progress, requests for input, and explanations of choices from the Safari project. Apple was brilliant to let him do this.

Take for example, a public exchange that took place between a Safari user (and web expert), Jeffrey Zeldman, and Safari developer David Hyatt. Zeldman posted a detailed comparison of his site on the Safari browser and the Mozilla/Gecko-based Chimera (now called Camino – good name choice, by the way). The next day, Hyatt posted a response explaining the reasoning behind the differences.

Hyatt was equally open and responsive to input when weblogger Mark Pilgrim posted his initial feedback on the Safari beta.

Hyatt is not alone in his process. Dave Winer (formerly) of Userland Software, Ben & Mena Trott of MoveableType, Brent Simmons of NetNewsWire, and many others all communicate and collaborate with the users of their software.

It is important to note that none of these projects are open source. Some, like Apple’s Safari project work with open source projects (the KHTML rendering engine, in the case of Safari), but they are not open source themselves.

This openness makes me want to use their software. It makes me confident that my input will be considered and my problems with an application might disappear in an upcoming version. I’ve seen desire for openness in software development drive software choices in a corporate development environment as well.

This is obviously not a large concern for all users. My parents are not interested in communicating with the developer of their browser – they just want their Hotmail. However, there is a large community of wannabe experts like me that collectively bear significant influence on choice of software (my parents are using Mozilla, because I installed it for them).

I would love to see other key Microsoft and Apple developers blogging (let’s see some key Microsoft and Apple executives blogging while we’re at it).


One thought on “Open Software Development Process

Comments are closed.