Tips for Starting Your First Open Source Project

Many organizations want to begin using open source but are unsure how to begin. With a plethora of products but a shortage of skills, deciding what the first project should be can be difficult. Here are five tips for starting your first open source project:

Start Now

If you wait for the perfect situation, you may never get started. You’ll learn far more about open source by working with it than you will by reading analyst reports, trade press, or the Wall Street Journal. There are many issues you’ll confront as you work through your first open source project, but you’ll only overcome them by confronting them. Open source differs from commercial products and starting your first project will help you understand how to work with this new type of software.

Start small

Avoid taking on too large a project with your first use of open source. A small project enables your personnel to not only work with open source products, but also to experience the nuances of the open source world. It takes a while to get used to the approach open source uses for learning and support; trying to get up to speed on open source culture while also trying to build a large system is asking for trouble.

Identify a small, relatively isolated system you can build with open source. One of the biggest challenges of larger systems is identifying and creating all the necessary integrations with the existing IT infrastructure. Try and minimize the integration work necessary for your first open source system. A perfect first system is a small, specialized intranet used by a well-defined organizational unit. For example, putting together a browser-based system that tracks IT services requests is a good first project. Everyone can access it to get a current status of the service queue, but only a few people need to insert or update data. Also, a system such as this probably doesn’t need to share data with many other systems, reducing the data integration burden.

Start with the right team

In every IT organization there are those who thrive on knowing the latest technology. They are invariably curious, with a tendency to treat setbacks as a spur to redoubled effort. Build your first project team with a healthy helping of individuals with these traits. People with these qualities won’t throw up their hands when a problem occurs – and problems are inevitable with your first open source project.

If your hard chargers have a tendency to cut corners on projects, treating, say, documentation as an afterthought (or a never-thought), leaven the team with some detail-oriented pragmatists. They will ensure that the project is fully realized as well as guaranteeing that this prototype project delivers functionality and learning (more on this shortly).

Staff the team completely. Even though this is a small project that uses open source, make sure that your team reflects your usual staffing practices. If your projects typically have a project manager who develops and tracks schedules, assign one to this project. It’s important that every function in your organization that will eventually be involved with open source be present at the beginning.

Start with a “real” project

The open source community thrives on an ethos of cooperation and informality. Projects using open source can be deceptively easy to get started due to the easy availability of open source. Because open source software is available at the click of a mouse, too many organizations download and start programming, neglecting many of the time-tested project principles used for commercial software-based projects.

This means that you should use your usual project methodology for your first open source project. Typically this means defining requirements, architecture, and deliverables. Because this is a first project, there may be additional items that need to be addressed that are common to any first use of software technology. It may be that developers need to be trained on the new product. Documentation may need to be procured. Furthermore, keep in mind your organization’s downstream needs as well. If an operations group will take on responsibility for keeping the new project up and running, make sure their needs are brought into the project plan.

Because open source is an unbundled product, with disparate parties responsible for delivering product elements (for example, it is rare for an open source development team to create training materials – they leave it to other entities to develop and deliver training), it can be a challenge to locate all the necessary resources for an open source project. The Open Source Maturity Model (OSMM), described in Succeeding with Open Source (Addison-Wesley, ISBN 0321268539) provides a formal process to locate product resources and can help ensure the organization has all it needs for its first project.

Remember, this is probably the first of many open source projects your organization will deliver, so it’s important to begin the right way. Just because the system is small is not a reason to avoid process.

Start with learning as a goal

Doesn’t this contradict the previous tip? In a word, no. While this is one of (potentially) many projects, it is also the first. Because of this, there will be a number of situations that will be novel to your staff. In human terms, novelty usually is associated with inefficiency. Don’t treat new circumstances as unacceptable roadblocks; accept them for what they are: A condition of using new technology in new ways.

Consider using more than one open source product. In addition to Linux, maybe the system should use MySQL as the data repository. Exposure to multiple open source products will increase your organization’s learning. It will also provide critical experience in understanding how to coordinate using multiple products, each of which has its own community. Because your first project is small (Tip 1, remember?), it will be easier to use several products in the system.

Because of the inefficiency associated with a learning experience, don’t insist on a positive ROI. Trying to achieve positive net present value in a first open source project can actually harm the organization long-term, as it may avoid product research, fail to explore alternative implementation approaches to discern the best technical path forward, and even shortchange training and documentation expenditures. The time to apply ROI requirements rigorously is when the organization is confident it knows how to work with open source.

Finish with a project debrief

Be sure to schedule a formal debrief on the project shortly after implementation. There will undoubtedly be lessons to be learned from your first open source project. Beyond the system functionality itself, the goal of this project is to help your organization become adept at working with open source software. Pay attention to what went wrong or even just went poorly – those are the areas that you need to address to get more benefit from open source. For example, you may find that downloading new versions of an open source product to obtain a bugfix destabilized the testing process, indicating a need for more rigorous configuration control. Perhaps it was not clear whether the necessary functionality for the system could be delivered by the chosen open source product -- the OSMM can help here, as it provides a structured process for assessing a product’s functionality. A debrief can be incredibly valuable in making future open source projects go more smoothly.

Conclusion

Starting your first open source project as both a “real” project as well as a learning experience ensures that the maximum value can be extracted from the project. Insisting that the project be staffed and executed like other projects in the organization enables the organization to see if it can apply its processes to working with this new type of software called open source. On the other hand, recognizing that the first project inevitably entails confronting new issues and problems allows the organization to increase its knowledge base and prepare it for future open source projects. However, the value that open source can deliver to your organization will never be realized unless you get started with your first project. Open source benefits can only be obtained by moving forward; neutral means no progress.