Open source

XIV.6 November + December 2007
Page: 33
Digital Citation

Managing a project with open source components


Authors:
Mitch Bayersdorfer

Managing large software projects is daunting. The demands of changing technology, customer requirements, schedules, and business competition can drive you to the breaking point. Depending on your needs, there is immeasurable value in open source code. Although it takes oversight, legal work, training, and additional management to accomplish, use of open source can dramatically improve your time to market and the quality of your product.

Imagine the following situation: You are leading a mission-critical project for a large corporation, you’re behind schedule, and you are understaffed and frantic. What to do? You start looking for answers on the Internet. A Web search finds a module that implements the exact function you need. Eureka! You have found just the code that will solve a critical problem in your project.

Wait—not so fast. Before you download and use that component, you need to consider all the implications of using open source software in your project.

The implications of using open source vary significantly, depending on the nature of your project and the license under which the code was released. It makes a big difference whether you are running an internal IT project that wouldn’t mind sharing its work with others outside the company or whether you have some uncopyable “secret sauce” that gives your product unique value.

Depending on how the much needed code was licensed, you may be setting yourself up for future legal, PR, and financial issues. You need to establish a structure that enables you to gain all the value of open source, while avoiding any potential pitfalls.

The quality of open source varies. Some mainstream open source code has had so much careful inspection, usage, and tuning that it would take thousands of person hours by the most experienced programmers to recreate. Other, more obscure projects may vary wildly in quality.

At ACCESS, we have set up an infrastructure which has helped us manage our open source projects. Depending on the nature of your project and the code you want to use, many of these steps may be helpful to you.

Step 1: Create an infrastructure to keep a record of all the code you download and use. It is critical to be able to trace back the source of any open source code you have in your project and to understand the license under which it was provided. To understand what you are allowed to do with the code you downloaded, and to understand anything else the code requires (such as advertising), you need to know the license that each module carries. Because the copyright holders of code may change the terms of their offering in the future or their website might disappear, it is important to know what the terms of the code were when you received it.

Step 2: Know your licenses. Before you examine and/or download the code, understand how it is licensed. If you are making a commercial product, you should get a lawyer involved, as interpretation of licenses is difficult and case law is evolving. Depending on the nature of the open source license and how your company interprets it, you may make very different decisions on how that code is handled and used. Certain kinds of licenses, such as the LGPL (Lesser General Public License), require derivative works to be released under that same license (some call this a “viral” license).

In some cases, such as the IT project above, this will be fine—your team will be happy to improve the world by giving the new code, based on the downloaded open source code, back to the world. In other cases, you may see that this requirement to release derivative works back to the community would subject your “secret sauce” to worldwide exposure. This means that the step of evaluating what software to use and how it is used in your architecture, based on its license, needs to be done with significant care.

Step 3: Research the component you want carefully. Get to know the project. Understand how actively the code is being updated. Find out its future direction. In a recent project, we chose a desktop-based graphical framework based on its popularity for a mobile device project. We found the version we chose at the start of the project had the performance we needed. But as the open source framework evolved to add more and more desktop features, the performance (which was still fine in a desktop environment) was insufficient in a memory- and MHz-constrained mobile product, forcing us to stay with the earlier version through the duration of the project. It would have been good advance work to gauge the focus of the community. At the time we made our choice, the focus was on adding features rather than performance; fortunately, performance work on this component is resuming.

Step 4: Teach your staff about open source. If you have proprietary code that you need to keep segregated from your open source code, you need to make sure that all members of your engineering staff understand this. Mixing open source and proprietary code may force you either to release code that you wanted to keep private, or to rewrite code in a clean-room environment so that you can prove it is “uncontaminated” with the open source code.

At ACCESS, we put posters throughout the company to remind people of open-source-usage rules.

Step 5: Audit the results. There will be times that certain programmers under tight deadlines may try to use shortcuts, copying code they find on the Web, without fully understanding its licensing terms. There are commercial tools (e.g., Blackduck) that can enable you to scan your code to understand the licensing terms of every line of code.

Step 6: Be nice to the community. Realize the value that people in the community create. They provide an infrastructure to release your derivative works and other code. For those pieces that are derivative works of open source code, submit your updates to that code promptly and frequently. This will not only help ensure that your changes make it into the public source base, helping ensure that you are not using a fork of the code internally (which would leave you “out in the cold” when the next version is released), but it also helps develop a good relationship with the copyright holders of the code, which can help influence the direction that the module takes. If your company has the resources, also contribute financially to those sites that help provide the infrastructure for open source communities.

Depending on your needs, using open source can improve your productivity. A few simple management steps can help you do so productively without dramatically increasing your overall risk. Go forth and be free!

Author

Mitch Bayersdorfer
ACCESS
mitch.bayersdorfer@access-company.com

About the author

Mitch Bayersdorfer has supervised program management offices at Apple and Sun and is now director of program management at ACCESS (formerly PalmSource), orchestrating the creation of the ACCESS Linux Platform. His interests include directing the Palo Alto Scrabble Club, reading, working out, spending time with his family and writing self-referential run-on sentences, like this one.

©2007 ACM  1072-5220/07/1100  $5.00

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

The Digital Library is published by the Association for Computing Machinery. Copyright © 2007 ACM, Inc.

 

Post Comment


No Comments Found