|
Editorials and Opinions
Guest View
Saving Trouble With Open-Source Software
by Bernard Golden
December 15, 2004 —
As open source becomes more popular, more and more organizations are beginning to implement open-source-based projects in IT infrastructures. When they do, however, they confront the fact that typical organizational practices honed to work well with commercial software don’t work perfectly with open source.
Open-source products are freely available, and so the parts of the project devoted to obtaining evaluation copies, contract negation and setting SLAs are all missing from open-source-based projects. On the other hand, open-source products come unbundled, so support resources must be identified and obtained, documentation and training resources located, and any professional services required found and assessed as to quality.
PLANNING YOUR PROJECT
Clearly, project management processes must be modified to address the realities of open-source products. Here are five areas to address in your open-source project planning:
Recognize the importance of project management for open source. Open-source projects themselves are managed in a rather freewheeling, consensus-oriented fashion with scheduling a low priority. Therefore, many people believe that an open-source-based project should be managed in the same fashion.
However, the realities of IT organizations dictate a different approach. IT projects must integrate with the existing IT infrastructure, and therefore often have to create connectors with other parts of the existing software stack. It is often critical to keep to a minimum the disruption the new system imposes upon other parts of the business.
Furthermore, go-live dates are often dictated by business objectives or the vagaries of merger and acquisition (or divestment) activities. These realities force projects to define deliverables, milestones and schedules. Therefore, a project using open-source products can’t avail itself of the “release no software before its time” approach that open-source development takes.
Address the additional work items posed by unbundled open-source products. Open-source projects excel at delivering functional, high-quality software. The availability and quality of the other product elements that mainstream IT shops require vary enormously between projects.
The size and nature of the product’s community [see “Community Rules,” Aug. 1, page 32 for more information on open-source communities] are critical for product support. Moreover, other elements like documentation and training that traditionally accompany a commercial product may or may not be available—and probably aren’t provided by the project team. Integrating the product into the existing software stack may be a challenge due to missing connectors that will need to be created. Of course, many projects require using outside resources that must be located and assessed for capability.
It is critical to recognize that using an open-source product imposes extra tasks to locate, assess and integrate these other product elements. Every open-source project plan should identify those tasks and build them into the project plan.
The Open Source Maturity Model (OSMM), presented in my book, “Succeeding with Open Source,” can help to identify and integrate these tasks into the project plan. No matter what process you use to help with these tasks, ensure that you have a project plan that addresses them. It is easy for their importance to be obscured by the ease with which open-source software can be downloaded, but too often the cost of ignoring them is paid downstream during project pilot and rollout.
Don’t overlook the prototype and pilot steps. Creating prototypes and pilot installations of open-source-based projects is more important than it is for commercial software-based projects. Working with open source requires new skills in all parts of the IT organization, from development to operations to the help desk.
It takes time to learn how to effectively use open-source support forums. Product integration, already alluded to earlier, can be a real challenge for open-source products, because integrations provided by commercial software vendors often go undone for open-source products. It may even be necessary for you to create product-specific documentation (installation guides, configuration documentation, etc.).
Building prototype and pilot installation stages into your project plan lets you discover these requirements while you can address them in a deliberate fashion. These stages “bubble up” shortcomings in product implementation and operations practices. You want to be handing out project team T-shirts at implementation, not frantically searching for missing admin guides.
Join the product community. While the ease of downloading open source makes it simple to begin working with an open-source product, there are real benefits to interacting with its community. Other people have probably confronted the same issues you will face with the product, and taking advantage of their experience can significantly shorten your product learning curve—and your project implementation schedules.
Furthermore, joining the product community makes it easier to engage with the development team, which can pay huge benefits as you implement the product. Interacting with the developers can make it much easier to obtain a necessary patch. Ongoing developer engagement makes it much easier to influence product direction—in ways that help your project.
Be aware of the soft deliverables required for your project team. Of all the project management techniques needed for open source, this may be the most important and least obvious. Open-source software isn’t better or worse than commercial software, but it is indisputably different.
When you create your project team, recognize that it will be made up of individuals with different open-source experience and enthusiasm.
There may be some zealots on the team who wax rhapsodic about open source’s benefits. By the same token, the team probably will include some open-source neophytes for whom this project is their first exposure to open source. Their open-source inexperience may be mixed with active dislike, due to the changed working practices needed.
An open-source-based project probably will have overt disagreement and covert resistance during its lifetime. Rather than dismissing the confusion and conflict, recognize that it is an inevitable companion to early open-source projects. Build time into the project schedule to allow extra interaction with team members. Consider teaming enthusiasts with open-source beginners as a way of fostering learning as well as respect.
Any new project is stressful, and an early open-source project is doubly so. If you’re building your project team, assign a project manager known for deft people skills. If you’re the project manager, recognize that you’ll be spending more time than usual in one-on-one meetings with team members.
Open-source projects are not easier or harder than commercial software projects—just different. As your organization begins to work with open source, keep these tips in mind to minimize problems and conflict. As the organization becomes more experienced with open source, the new tasks will become more familiar and will cause less challenge, while the formerly critical skills of vendor negotiation and escalation will be less important.
The important thing to keep in mind is that your project management experience will need to be upgraded to succeed with open source, but not thrown away altogether.
Bernard Golden is CEO of Navica Inc. an open-source consulting firm, and is the author of “Succeeding with Open Source” (Addison-Wesley, August 2004).
What Do You Think?
SD Times welcomes feedback. Letters must include the writer's name, company affiliation and contact information. Letters may be edited for space and style and become the property of BZ Media.
Send your thoughts to letters@bzmedia.com, or fax to 631-421-4130. Please mark all correspondence as Letters to the Editor.
|
|
Advertisement
Back To Top
|