Come with me, close your eyes, and imagine a world filled with excitable programmers and software users who love free software. One such user, we will call her Bertha, loves to write software, and has always dreamed of writing the one true weather reporting panel applet. Bertha sits back, stretches her fingers, shaking with excitement, ready to jump into the world of free software, and, and…registers a Sourceforge account.
Bertha is wise to the ways of development. She knows she needs a CVS server, mailing list, website, bug tracking system, forums, feedback reporting systems, download repositories and more. All of these services are available to her and she has seen her favourite projects with such ample resources. Bertha wants her panel applet to be the queen of panel applets, reputed for weather reporting accuracy and an exquisitely designed configuration dialog box, so she sets forth to hunting out documentation on each of these resources. She explores the joy of patches, creating CVS branches, handling mailing list subscriptions, developing a careful revision system and other fun filled aspects to her project. Unfortunately, it is all a bit much and after a few commits to her CVS account, Bertha rapidly gets bored and her legendary spectacle of weather reporting joins the other poor unmaintained souls that wretch in Sourceforge hell. Damn.
The moral of this story is one of overreaching the potential of a project. When Bertha had the idea for her software, she also had a clear idea of how she was going to run her development environment and handle input from other hackers. The problem with her approach was the fact that she expected user input from the community when little or no code was produced initially. She also created a number of resources and discussion mediums for a project that essentially did not need them. There are a great many dead mailing lists, chat rooms and forums that have been exhausted from the over-excess of resources. If you go to a forum community with ten forums available, you are likely to have a little conversation in different parts of the site. If you visit a discussion site with a single forum, the discussion is concentrated better and given the opportunity to flourish and develop relationships between the members, with a sense of peer review and aspiration.
The problem we face is an excess of software consumption. I am certainly not exempt from this sordid story, and let me share with you an example. A while back I decided I wanted to do some XUL programming. I downloaded every possible XML editor I could find, documentation parsers, validators and other utilities and tools that were even loosely linked to XML. The same applies to GUI programming; debuggers, editors, GUI dialog designers, profilers, documentation generators, source highlighting tools and other things have clogged up my system over the years. Most of these tools were used in a context that only scratched the surface of their capabilities. There is a distinct feeling of potential and the security of being armed to the teeth with tools if you have everything available to you at your fingertips. This rapidly growing library of free software and documentation is resulting in less time for us to actually learn these tools in depth. I am certainly not unhappy with all of this choice of free software, but there is a certain level of understanding that can be achieved when you only have a single tool and you need to know how to make use of it well and in a number of contexts. As the old saying goes, “a jack of all trades, but master of only vi”. Oh, hang on…no.
The concern I have with this culture of padding ourselves with resources, utilities, tools and other fluff, is that we are putting projects up on a pedestal before they have had the opportunity to grow and develop. With the example of Bertha and her project, if she had simply worked on the code herself until she had something useful, she could have then simply put it on her website with an email address to send patches to. If Bertha started receiving patches, it would then warrant the possibility of setting up further resources. If on the other hand, Bertha did not get anything, or she lost interest, or didn’t have time to commit to the project, she has not lost a dot. By having yet another dead Sourceforge project we are reminded yet again of a free software failure that could have actually achieved something if the time was spent on the software as opposed to arranging CVS accounts and mailing lists for a project that would ultimately fail.
The same dilemma is really affecting advocacy of Linux and free software. There are so many organisations and schemes that are touted to further the software we all know and love in weird and wonderful ways. These organisations then get set up and begin discussing how their organisational systems should be set up and operate. Typically arguments about frivolous subjects such as whether they are going to use Perl or PHP as their website scripting language are argued, debated and ultimately thrashed out on a mailing list. All of this red tape then occupies up the precious time of volunteers who only have a certain amount of time that they can spare in between work and family commitments. This red tape not only wastes effort but can also hinder morale when little is achieved.
I am a believer of a practical hands on approach to software development and advocacy. I used to be of the opinion that every project, no matter how big or small, needs a full-on branding campaign to give it a professional and viable look and feel. This is valid for established large scale projects such as OpenOffice.org, KDE, GNOME and Mozilla, but for new projects such as Bertha’s little panel applet, this red tape and fuss is a lot of effort over nothing. I firmly believe that you should spend as much of the time you dedicate to free/open software and actually spend the time doing real, tangible, measurable and pragmatic things. If you are advocating Linux, instead of writing rules and regulations on how your advocacy project should manage its resources and how its official branding should be created, just get out there and call a person/charity/school/business and get on with it. The red tape will be needed at some point, but not until a stage when you are becoming a big noise in the advocacy world and when you are working on lots of different projects with different members.
So, what do you think? Have you any experiences that preserve one view or another? Do you support an established system or prefer a freeform development route? Scribe your mumblings below…