Articles / Developing with Open Source

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!


Peter 'darkewolf' Crystal is a regular annoyance on #linuxaus (irc.openprojects.net) and also is a maintainer for a number of packages for the Debian GNU/Linux project. He has completed four years of a three year degree in Multidisciplinary Science with a major in Distributed Systems and Computer Communications. He has a lovely family which doesn't take up nearly enough of his time. He is currently working on a 'Open Source Development Guide' of which this editorial is a highly condensed version.


T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

Recent comments

28 Mar 2000 02:44 Avatar brianbehlendorf

Paying open source software developers.
How about this for a bizarre concept, hire developers to write Open Source code.

Sounds good to me!

Brian

26 Mar 2000 08:57 Avatar neilcherry

Re: The Motivation Factor...

At the same time, you have to wonder that if (when?) the open source movement really catches on, why would anyone hire a software developer?

Why develop software when someone is giving away the source to a perfectly usable product?


Both are good questions and I hope you'll find this a useful answer. Remember that most companies need a specific piece of software that has to be written. They have spec's that have to be followed. If there is nobody working on that kind of software or the projects are close but don't meet the specs then you'll need to hire someone.

How about this for a bizarre concept, hire developers to write Open Source code. You create a contract that the developers must meet certain milestones (the developers must agree of course). Because the code is open and available you don't need to worry about losing the source should it disappear with the developer. And it can benefit form peer reveiw. I'm certain I have some holes in my logic but I think you get the general idea. I beleive there is a site which supposedly pays for Open Source projects. And now I'm going to try to find some financial backing for part of my Open Source project Linux Home Automation. I could never afford to purchase all the HA controllers that are available. But maybe I could convince the manufacturers to get our hands on their products so we could write software for them.

--
Linux Home Automation - Neil Cherry - <A
HREF="mailto:njc@dmc.uucp">ncherry@home.net
<A
HREF="http://members.home.net/ncherry">http://members.home.net/ncherry (Text
only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
http://linuxha.sourceforge.net/ (SourceForge)

26 Mar 2000 01:46 Avatar leonbrooks

Darkewolf's new job can't be working him too hard!
Within weeks of getting his new, high-paying job at mbox.com.au, Peter now has time to write articles? I don't understand! (-:

25 Mar 2000 17:44 Avatar beewar

A great article...
I know there are a lot of developers out there who only cares about the pure hardcore coding. But planning and structurising is just as important, and without that, any project is doomed to fail.
When it comes to the opensource thing, I dont even consider it a question. All opensource software has a huge advantage in both portability, bugfixing and testing. And actually I think its a coders duty to deliver back his or her code and ideas, which are in almost all cases are based on earlier code and ideas. But this is maybe a little offtopic...

25 Mar 2000 14:17 Avatar vulturex

The Motivation Factor (otherwise known as, how to make a living)

This piece only briefly touches what may become a very important issue for the whole free (libre) software movement:

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.

- Peter 'darkewolf' Crystal (mailto:darke@indigo.net.au), "Developing with Open Source (http://www.freshmeat.net/news/2000/03/25/954046740.html)"


I know that this issue has been discussed ad infinitum in many arguments about open source, and I also know that there are a number of companies who are making money with open source related products. At the same time, you have to wonder that if (when?) the open source movement really catches on, why would anyone hire a software developer? Why develop software when someone is giving away the source to a perfectly usable product?


We may see a massive reorganization of how software is funded. More integration between the hardware, software, and support companies, similar to the business plans of RedHat (http://www.redhat.com/) and VA Linux (http://www.valinux.com/), seems to be an obvious direction. We may see an increase in contract programming, where a company is hired to add a new feature to their software, or maybe the SourceXchange (http://www.sourcexchange.com) style of bounty programming will be popular.


At the very least, commercial software companies as well as the open source community should keep a close eye on this situation. If the market really does begin to change how financial rewards for creating good software are distributed, anyone that is not ready for the new economy may miss out.

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.