Developing with Open Source

Peter 'darkewolf' Crystal writes: "The Open Source phenomenon threatens to overtake us all. IBM is supporting it strongly, Sun is doing it, and even the bane of existence -- Microsoft -- has an interest in it. But where does that leave developers and potential developers that have found themselves called to this clandestine world?"

Seasoned Developers

People that have been developing software for the commercial market for some time will have some idea of how you go about developing software. Migrating to a new market and possibly a new toolset won't cause them too much trouble. In fact, many ex-commercial developers have contributed useful tools that mimic the closed-source equivalents. The developer can create the tool he's used to and then add the features he wished it had. The best example that comes to mind is cgvg, an almost-clone of cscope. Cscope lets a programmer dig through source code to find where something is defined and where it is used. cgvg replicates this functionality using Perl.

The seasoned professional might need a little pointer toward the particular tools that are available, but once she's headed in the right direction, the process of development should not be a hassle. The only obstacle for ex-commercial developers when it comes to developing Open Source software is the justification. The connection between code and money is no longer obvious. You give away the thing you have spent hours writing.

Neophyte Developers

But what about the enthused youngster that just installed GNU/Linux for the first time or the mathematics professor that is watching FreeBSD seamlessly build? Their minds are full of ideas, they know their code, but their experience from the university only provided them with vi and gcc while they learned. They don't know anything about the tools that are available, nor do they understand the design methodologies that large projects require.

Unfortunately, neophytes will often assume that the tools are the most important aspect of developing their wondrous ideas while, more often than not, the approach to the development is where their energies should be invested. Those five extra minutes per session documenting changes could make the world of difference when someone reports a bug three weeks down the track.

Tools

Good places to start finding out about the tools available are sites like freshmeat and search engines, and of course it's always good to ask people that do development themselves (IRC is a great way to do this). It is important to remember that not all tools are directly related to code. How are you going to track the time spent on each part of the project (doing this is great for working out how to distribute the workload later)? How is it going to be advertised? In what format do you want documentation?

The Approach

Tools are only part of the picture. How the project development is handled is the crux of the matter. The mathematics professor is a one woman team. Should she just load the editor and start hacking away at the keyboard? Definitely not. As any university course on software design and engineering teaches, and as any software house will say, all software should be designed first. State what its function will be. How will it do this (the algorithm)? How will it store its data? From there, you have an outline from which to start coding.

"But I am just one person!" you call. Maybe so, but if the program gains interest and has potential, it could be the next Apache or even the next Linux. Why spend time developing it from one person's point of view, only to have to restructure the whole thing sometime down the line to allow for five developers, or five hundred? Play the many roles necessary for development. Have different accounts for documentation, code development, and PR (Web page design). With today's UN*X-like operating systems, making new accounts at home is easy. Treat the roles as if they are different people; wear a different hat each time you perform each role if that helps you remember. By separating the roles, they can be easily assigned to other people if the need comes up.

Be very strict about the project. Write guidelines on how the code is going to be formated. Write guidelines about the extent of documentation required both in the code and externally. And then stick to your guidelines. This way, you'll understand the code in two months time, but more importantly, if new developers join the project, there will be some consistency and cohesion to it.

Peer Review

Peer review is an important factor of the Open Source movement. You are provided with a world wide audience that is quite willing to look at your creation and critique it for you. The good and the bad points will be explored in great detail (usually in a mature and sensible manner, but as with anything, there are a few bad eggs). If your project is even slightly useful to at least one other person, you'll get bug fixes and feature suggestions, making the work load easier for you.

It has been said that Peer Review is what drives the Open Source movement and makes Open Source a community rather than just a licensing issue.

Why?

Why would you want to develop Open Source software? Because you can. There is nothing to keep you from writing the perfect text editor or the best accounting package possible. Why not write for the ego of it? If you write something that is impressive enough (either through eye candy or rock solid design), people will talk about it, and your name will be mentioned. Why not be the next Linus or Larry Wall or even the next RMS? Write a program for the pure love of it, and watch your program make thousands of people's lives just that little bit easier because your word processor adapts to their needs as they go.

With free tools, free help, and an enormous community spirit, even the most grandiose idea can be accomplished. Think of it as programming the minds of your users and potential future developers. Load them with code in the hope they'll execute it. Code for their machines, and code for their minds. In the same way that your software provides the logic to perform a machine function, the documentation provides the user/developer with the logic to do the same. Share the code, spread the word!