A journey into open source

Open source can help you develop your product, but it can also open a door to a better way of working with other developers. Learn what one developer discovered about open source projects.
Written by Roy C. Hoobler, Contributor
The projects I manage and develop in the office are seldom as exciting as my own projects brewing in the basement. For years, I’ve spent late nights and weekends working on my own projects at home, and it’s taught me a lot about programming, especially in XML and Java. I usually start a project because I want to learn a new technology, or I remember a "Request For Proposal" at the office that was never answered but might be fun to try. These extracurricular projects keep me learning continuously and satisfy my workaholic nature. That’s great for my career, but in many ways, it’s also frustrating, especially when I feel I’m onto something that I’d like to take to the next level. Then I found open source.

Developing software all the time
The latest of my homegrown projects is the Sonoma Portal, an XML/Java-based portal server. I really wanted to continue this project and develop it into a “commercial” product, so I started asking questions. A Mandrake Linux employee suggested registering the project as open source software. I’d visited SourceForge.net and Freshmeat.net before, so I gave them another look. I was a little hesitant since it’s a big commitment to manage an open source project with all kinds of people reviewing your code.

Getting my software and ideas out there
After summoning up the courage, it took about two weeks to get the code for the Sonoma Portal stable enough to post on SourceForge.Net. It surprised me that hundreds of people viewed the project details not long after. The beta 1 version was downloaded over 30 times in a two-week period. Going it alone or starting my own Web site would never have generated such interest—and I’ve tried it with other software.

The difference between open source and custom development
For now, the Sonoma Portal open source project is all about the product and the developers. The requirements are simple, there is no budget, and tasks are assigned and completed. I keep a schedule, but I keep it flexible. If a big problem arises, it costs time, but nobody has to worry about coughing up more money or explaining things to a client.

Open source lets me offer up any number of alpha and beta releases while continuously improving the code. Other open source projects, such as MySQL or Apache, have been going on for years and might have 15 total releases, but only for version 2 of the product. This is the opposite of commercial software, which often skips beta releases and version numbers.

Open source concerns and benefits
Learning how the open source community works is an ongoing project. The source code is placed into a Concurrent Versions System (CVS), which takes time to learn and discipline to use correctly. Managing tasks and developers is a job in itself. Some of the developers that joined my project left before it really got started, and it’s taken more time than I thought to get everyone up to speed. As the project grows, it will be interesting to see if anyone remains as committed as I am to the project.

Open source’s biggest advantage is that everyone wants to do things the right way. Bugs are honestly reported, investigated, and fixed. Documentation becomes very important. New developers who join the team generally have a lot of questions. Good documentation and the messages posted in our developer forum do more to answer such questions than is typical in the corporate world, where the project manager spends most of the day replying to e-mail. In my open source project, we’ve all agreed on most issues, and all comments have been helpful.

By the time Sonoma beta 3 is released, it will be many times better than beta 1. We’ll also release beta 2 about five weeks after beta 1. Without having the open source "frame of mind," I wouldn't be committed to managing the project, devising a plan, producing documentation, and setting goals for releasing future versions. At this rate, we should have a good product in about six months. Feel free to check on the status of the project.

Taking it to the streets
I hope that, as people use the software, it will become a legitimate portal or small content management solution and a viable alternative to commercial offerings from companies like Ektron and iLevel. As far as getting the word out, open source publications and media outlets like Linux magazines and Slashdot can help.

Success is its own reward
For any developer, the best reward is finishing a challenging project and seeing people use it. I get the feeling that my open source colleagues have the same attitude I have: "Let's develop a good product, learn and advance the technology, and see what happens.” Apache, JBoss, and even Linux all started out as small open source projects. If the Sonoma Portal is a success, we’ll have a lot to be proud of. If it never makes it out the door, we’ve still learned a lot about project management and teamwork, and the technical knowledge we’ve gained will help us in our professional careers.

Editorial standards