When developing Open Source software, you may not think you need to spend time educating the public about what you are doing. It is easy to fall into a comfortable lull that multitudes of commercial Open Source press releases have contained just enough factual information amongst spin to educate the public.
What I have found is far from that. It is critical that Open Source developers start thinking about the message they put out with their software and begin to understand the fundamental distinctions between proprietary and Open Source software that the public may not be educated about.
Most of my Open Source software is distributed through download sites that offer the facility to review the software following download and some use. These sites are quite different and considerably more brutal than the warm fuzzy Open Source sites, however they reach considerably more people and they account for roughly 80% of my Open Source software distribution. In terms of getting software to people, they work.
The downside is that people who download the software may not distinguish or understand the differences between Open Source and proprietary software. I would like to think that my Open Source development could compete and beat proprietary development on a number of levels other than the straight warm fuzzy ethic.
I think there are strengths in the Open Source model where proprietary software fails. To illustrate this, my wife (less ideologically driven than the author) bought an off-the-shelf Windows machine recently. As this was the first opportunity I have experienced in a number of years to come close to a minimum spec machine, I purchased four games for the machine.
All the games came in DVD cases and they all had relatively similar installation rituals. In general it took about 15-30 minutes of installation before I could play the game. The general format was very similar in terms of introduction, titles and credits then I had some flexibility with the gameplay. Of the four titles, one didn't work. It crashed within the first 30 seconds of running through a number of configurations. I was really disappointed. Out of all the games I had purchased, this one was the one I was most looking forward to playing. And yet, I had no recourse. The money had been paid to the company. I could return the game, but unless I purchased another computer that could run the game, I wouldn't be able to have the experience of playing the game ever.
Thus the proprietary model may in the long run give me financial restitution for this defunct purchase. But I won't be able to play the game. Although I have lived in an idealistic vacuum of poverty computing up until now, it struck me that Open Source just isn't like that. If the software was Open Source, someone along the line would have been able to tinker with it to fix the problem that caused it not to run.
I have reduced the number of releases I do per year because of the emotional kick in the guts I get through the comments left on download sites. I haven't done the statistics but I suspect I would release probably double the number of times per year if I didn't read the reviews that come up on download sites.
The negative reviews on download sites fit into two categories. The first are letting off steam reviews where the author spends no time describing anything that could be factually used to improve the software. These I find the most frustrating. If there were actual problems that could be resolved in their use of the software, they could report them directly to me. This category comes from frustrated users of proprietary software who don't understand the distinction between proprietary and Open Source. They don't understand;
(i) the user can actively contribute to the improvement of the software through providing information to the developer,
(ii) that this information drives a large part of Open Source development, and,
(iii) that this is really the responsibility of the user.
The second group of negative reviews contain actual improvement requests or information which can improve the software. These typically aren't pleasant reading either. But they do actively improve the development of the software and they can be charted and resolved.
Generally negative reviews miss the point of the software and that is fundamentally my responsibility as an author to provide documentation both prior and post download to explain exactly what the downloader is getting.
I have thought considerably on how the public can be better educated about the strengths of Open Source. The best, and perhaps most challenging, way is to write better software and to show the distinctions in the quality of the software that is produced.
Open Source to-date has been about scratching itches and often times these itches are indicative of the kind of work Open Source developers do, as opposed to the kind of software the (general) public is interested in using. I have tried to address this in my own development in documentation and the kinds of software I develop. I think there are a number of software genres that are unrepresented with Open Source development. Many present more challenges than the existing Open Source successes.
In conclusion, educate with your work and with the information you provide with it.
Tom Barbalet, 8 February 2004.