The system, man
 | ||
 | Email weblog link | |
 | Blog this |
Jono Bacon
May. 18, 2004 03:59 AM
Permalink
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.
Jono Bacon is an award-winning leading community manager, author and consultant, who has authored four books and acted as a consultant to a range of technology companies. Bacon's weblog (http://www.jonobacon.org/) is one of the widest read Open Source weblogs.
Showing messages 1 through 7 of 7.
-
Project Fanfare
2004-05-23 19:31:21 spector30 [View]
-
Sounds like...
2004-05-22 16:09:54 scaleswell [View]
Sounds like cathedral and the bizare not to mention a little obvious. Build it and they will come does not cover the topic either. Just ask Tanenbaum. In the real world, it's hard to be successful on the merit of your work alone.
-
Flip side
2004-05-18 07:32:59 GJJ [View]
The thing about sourceforge is that that dead source code is still out there. It is possible that someone, recognizing the potential of what is there could come along and jumpstart the lagging project.
I am curious if this has ever happened. -
Flip side
2004-05-18 12:49:40 brian d foy |
[View]
I have helped transfer a few dead projects to other people through SourceForge, and I do this several times a year as a Perl Authors Upload SErver (PAUSE, the gateway to CPAN) admin.
No matter how old code gets, it does whatever it did, and keeps doing so. -
Flip side
2004-05-18 11:01:59 chromatic |
[View]
It happens occasionally. Consider, though, that many dead projects on SF don't have any code at all!
Jono's absolutely right; it's a mistake to think that a little project will run like a really big, successful project. It may, in the future, but it won't happen all at once.
-
Flip side
2004-05-18 09:36:41 dscotson [View]
Recently there is the Wordpress project (getting a lot of buzz, especially after Moveable Types recent PR missteps) that was born out of the ashes of b2/cafelog.
http://photomatt.net/archives/2003/05/26/wordpress-now-available/
You can check out the activity stats here (note that people were still coming to see the site (red) but stopped downloading things (blue):
http://sourceforge.net/project/stats/index.php?report=months&group_id=51422 -
Flip side
2004-05-18 08:11:17 jwenting [View]
Nice in theory but highly unlikely in practice.
Everyone likes to write new fresh code, not regurgitate old dead code by others.
That's why there's a gazillion projects all doing basically the same thing in slightly different ways.
If you have the choice to start a new project, join an existing project that's actively maintained and does almost what you want, or adopt some dead codebase that noone's touched in 2 years, which would you do?
Remember people will look at the sf pages for the dead project and see it's been dead for 2 years until someone picked it up again.
They'll likely decide to watch and see what happens before jumping on, leaving you to muddle on alone.
And that's IF you can get in contact with the original maintainer to get the administrator's password for the project so you can add yourself as a committer and administrator when that person has likely changed email addresses several times or if you're lucky just forgotten they ever started that project.
| Showing messages 1 through 7 of 7. |
Return to weblogs.oreilly.com.
Weblog authors are solely responsible for the content and accuracy of their weblogs, including opinions they express, and O'Reilly Media, Inc., disclaims any and all liabililty for that content, its accuracy, and opinions it may contain.
This work is licensed under a
Creative Commons License.
Our developer worked feverishly for 6 weeks and got us a barebones, functional system. It was at this point that we tested the heck out of it. We reported bugs directly to him and within hours they were fixed. After two weeks of this the system was solid enough to show others.
It was at this point that management sat down with the developer and tech support. They looked at what we had been working with. They made their suggestions and a couple of weeks later we met again. This time management was really impressed. We had a system that met tech support, management, and customer needs. For nothing more than giving one person the time to work on it.
The branding part of the project did not come until well after an established code base existed. This was as I feel it should be. In the above example it gave the developer and his manager leverage to get more resources to fully flesh out the project and gain wider support for it a little bit at a time.