Your First (Real) Open Source Project

OK. Having read Parts 1, 2, and 3 of “Why Your Future Depends on Open Source,” you’re convinced. You need to get on the bandwagon.

What should your first open source project be? Many organizations begin with a Linux migration project — migrating an existing set of commercial applications from a platform (often Unix) to Linux (either Red Hat or SuSE) running on commodity x86 hardware.

But I’m not talking about that kind of project. Rehosting a commercial set of apps to a commercial version of Linux provides an economic payoff, but really doesn’t scratch the surface of gaining open source benefits. This type of project is kind of a halfway-house of open source. More to the point, this type of project doesn’t really help you prepare for the world of open source.

So what kind of project should you choose as your first open source effort?

Well, first off, this may be your first official open source project, but it probably isn’t the first open source project in your organization.

Remember that “must have immediately” system a couple of your people threw together toot sweet with no budget? They probably used open source. If your organization is typical, you will have one or more skunk works projects that are open source-based.

Even though these systems use open source, however, they aren’t really good prototypes for your organization’s initial experience with open source. Why?

Well, by virtue of being skunk works projects, they — by definition — bypassed all your organization’s official processes. They were probably built by your most curious, intelligent, tireless employees — in other words, people unrepresentative of the bulk of your organization. You can’t tell from a one-off, firedrill, brain trust effort what open source will mean in your day-to-day workload.

To really understand how to take advantage of open source you need to run a project in the full light of day with a mix of employees — some diligent, some distracted, some resistant — representative of people assigned to any project in your organization.

You need to manage the project with the same kind of process that you apply to all your other projects.

Only by using open source in your standard setup will you be able to recognize how it differs from standard commercial software and what changes you’ll need to make to your standard operating procedure to address those differences.

In other words, use your first open source project as a testbed and a learning experience.

On the other hand, trying out open source may not be universally favored within your organization. As the saying goes, change is stressful, and therefore resisted. Many times, the way organizations repel initiatives is to follow process doggedly and ensure failure. It’s called “working to rule.”

So don’t just launch an open source project into your organization and wait for good news to come back. You need to strike a delicate balance — enough attention so that everyone understands you won’t accept passive resistance, while not pressuring everyone for only positive feedback.

Insert several “lessons learned” milestones into the project plan. Ensure that you take time to get feedback about the experiences your team has had working with open source. The areas you’re likely to find different are:

• Documentation. Open source documentation can vary widely by individual product. Certainly the expectations of open source projects as to the minimum level of acceptable documentation differ from commercial expectations. Poor documentation is especially troubling to less-motivated team members, so expect to hear about it.
• Architecture. You may be used to getting roadmaps and architectural assistance from your vendors. You need to be more self-reliant with open source; the community (see below) can be useful in this regard, but expect to do more trolling around the Internet to find out how other organizations have used the product in question. 
• Community. This word is bandied about a lot regarding open source, but a product’s community quality is a key issue for any open source product. Learning and getting support from other users can be a new experience, so give everyone a chance to get acquainted with how to work with open source communities.

What kind of project should be your first open source-based project? Don’t try to boil the ocean. Find a project that is fairly self-contained (not too many integrations with the rest of your infrastructure), isn’t a key part of your production environment, and has well-regarded open source products available.

A perfect project is an internal portal used by the IT organization itself. There are a number of open source content management systems (Drupal, Mambo, Plone) as well as open source wikis that can be used for this purpose as well. Internal portals won’t affect the rest of the company while you’re getting up to speed on open source. Finally, portals can usually stand alone and typically aren’t part of your production environment. This makes them a good candidate for an open source pilot project.

At the end of the project be sure to schedule a debrief to document lessons learned that can be made part of your internal processes. That way, you have a consistent, productive set of working practices that you can apply to any future open source-based project, ensuring that future efforts will go more smoothly and without starting the learning curve all over again.