One of your best developers comes to you with a unique proposal. Instead of writing software from scratch, or begging for the budget to purchase an off-the-shelf solution that would need customization anyway—well, there’s an open-source application called Foobar that does nearly everything on the wish list. The developer suggests that she could extend Foobar’s feature set, and then contribute the enhancements back to the open-source community. This way, when the next Foobar version is released, it won’t need the custom changes made all over again. And the only cost is her salary.
You’re sold. It’s a good idea, technically and financially. But it’s your job to integrate this in-house open-source development project into an enterprise setting. Some challenges are obvious, such as the intellectual property concerns your legal department will raise. That’s a topic of an upcoming article.
But there are other things you should know before you blurt out, "Sure, go ahead and spend 20 hours a week working on Foobar!" In this article, several managers and developers who have learned these lessons—the hard way—share their experience.
This is not a theoretical exercise. According to Evans Data, nearly two-thirds of developers in North America use open-source modules in the applications they write. And sometimes, their involvement goes far beyond contributing bug fixes back to the community.
Small contributions may involve a single employee who, on his own initiative, changes an open-source tool to increase productivity for himself and his team. Or your firm may contemplate a corporate strategy built around moving major chunks of functionality into open source.
The Temporary Fix
Sander Marechal works for a large multinational corporation in a regional IT support position. After his company acquired a competitor, IT was a mess—just as you’d expect in a merger of two big companies with different architectures. According to Marechal, the merged IT departments didn’t have a central IT call registration system. While upper management was busy deciding on a vendor, the IT people were stuck with Excel spreadsheets. Says Marechal, "My boss knows I am pretty good at developing Web applications. I do the same thing in my free time. He asked me to design and develop a system that would bridge the 1.5-year gap until a commercial system was implemented. To do so, I brought in my homegrown basecode which was derived from phpBB 3.0 Alpha and thus under a GPL license. No problem, since the system would only be used in-house."
Meanwhile, the commercial system was already a year late. Several additional company sites began using Marechal’s system, which he spent time enhancing to meet their requirements. But since the original code was GPL, Marechal asked the boss if the system could be released to the public under a GPL license. This way, he says, "The work would not be lost in corporate amnesia when the commercial system finally comes." The boss agreed, and the first public release is expected in April 2007.
This is not occurring in a bastion of open-source freedom; Marechal’s company (which is a household word) has no open-source policy. Everything is proprietary. "As far as upper management knows, it’s a 100 percent Microsoft shop (except for all the BSD and Linux boxes the geeks keep sneaking in through the back door). The decision to open source my application was purely a one-off. A fluke," says Marechal.
It isn’t a fluke for everyone. Some companies are actively participating in open-source projects, with some of their programming staff working part- or full-time on such software. The best known of these is perhaps IBM, which developed Eclipse, then successfully spun it off into an open-source project—yet has a significant number of developers working on the project.
Nor is this an endeavor specific to computer industry vendors. You can find open-source committers writing code—on the company dime—at companies of every size and in every industry. The only criteria are the benefits that everyone gains. "For a company, working on an open-source project is a two-way street," says Grahame Grieve, project lead for the Open Healthcare Framework Project and CTO of Jiva Medical. "The company needs to benefit, and the open-source community needs to benefit. This mutual confluence of needs and outcomes is what drives open-source involvement by any company, either big or small. If it turns out to be a one-way street, in either direction, commercial pressures will bring the process to an end."
So, how do you make it work?
Define Responsibilities Clearly
"In general, the biggest issue is determining who controls the objectives," says Richard Laager, a developer at the Wikstrom Telephone Company in Karlstad, Minn., and an active developer on Gaim and a couple of small Gaim plug-ins such as IRC Helper. A developer who works on an open-source project may—and some might argue eventually will—experience conflict between the open-source community’s needs and her "day job."
As a manager, that means you need to be prepared, by carefully defining responsibilities and determining the scope of the developer’s involvement. Few have as much experience with such tasks as Syd Weinstein, who was the coordinator of Elm, an early open-source project from 1986-1998. Elm had 40 developers from around the world, and PacBell paid one to work just for Elm. As president and later CTO of Myxa, a technical services/consulting firm near Philadelphia of about 30 people, Weinstein says the company had several developers working with Perl and contributing code back to the CPAN Perl archives, in the GNU license. Weinstein cautions that managers should contemplate how the open-source project affects the remainder of the workload; can they use it to improve the employee, morale or forward the progress of related projects? He suggests that you seek out answers to questions including, "Can you draw a clear line of what is to be contributed and what isn’t? Can you provide sufficient security on code bases, or shared areas to prevent access hacking?"
For example, like any other project, the open-source programming has to be folded into other corporate and team priorities. Marechal can work on his project in the slow hours, but his work in application support comes first. When work increased due to a coworker’s long-term illness, it meant he had very little development time and a backlog of requests from several sites. He says, "I now consider such internal requests as general application support so that I can schedule it in with my other work. Development initiated by myself without a request is still regulated to the slow hours, though."
Yet, open source never sleeps, pointed out Penny Leach, a developer at Catalyst IT in Wellington, New Zealand, and a committer on Moodle, an open-source learning management system, and Elgg, the open-source social networking tool. She’s also one of the lead developers on Mahara, the open-source ePortfolio system. "I am paid to work on open-source projects during work time, but often bugs appear on my weekends; that’s something that has to be managed." The open-source community expects that if a bug appears, a developer will turn her attention to fixing it. Most developers are cognizant that paying work has to come first. Yet, says Leach, "A response like, ’Well, I work on this project on Tuesdays and Wednesdays, so wait until then’ is not going to cut it."
The only solution is flexibility. Leach suggests that a manager who advises the developer, "You can work 20 hours a week on this" should probably mean, "You can work 20 hours a week whenever you need to" rather than, "You can work Tuesday and Wednesday." Weekends are harder, she cautions. "The company I work for is small enough that if I spend a couple hours fixing a bug on the weekend, maybe I’m late on Monday, or leave early. That’s probably not going to work in a larger or more corporate institution, so if it’s going to be an issue, agree on a strategy before work starts."
Who Chooses What the Developer Works On?
For many developers and their managers, a major frustration is the need to resolve conflicting pressures from different areas. Managers should understand that company goals may conflict with the project goals; company goals may need to be altered, dropped, or addressed as plug-ins, in-house patches and so on.
According to Leach, clients, the company and the open-source community all put demands on the developer. "Often, the needs of the open-source community force us to make a trade-off with a particular feature. For example, a client wants a feature that does A, B and C, and we write a proposal and pitch it to the community. However, the maintainer of the project might say something like, ’That’s nice, I like A and C, but I don’t like B and we also need D,’ which makes it difficult for us as the person in the middle between the client who want B, and the community, who won’t accept the feature unless we write D."
Generally, the way Leach resolves this conundrum is to compromise and to write the entire feature with A, B, C and D, but to do it in such a way that bits can be turned on or off, or A-D are plug-ins. She says, "That way, we keep the community and the client happy. The feature gets accepted into the next release; everyone wins." That’s not always a perfect solution; sometimes this doesn’t work, and B has to be maintained as a patch, but Leach says, "It’s important to try really hard to find ways to avoid that."
Laager’s open-source involvement rarely involves his company. But based on his experience, he says, if his boss picked the objectives, he’d brace himself for a couple of problems. First, given an easy way to accomplish something, and also a better way (that involves much more work), the open-source project would prefer that things be done correctly. The company may prefer the quicker solution. "If a manager is going to allow an employee to work on an open-source project on company time, they’ll need to be understanding of the fact that open-source projects expect things to be done correctly, regardless of the amount of effort and time that takes," Laager says.
Also, Laager would be concerned if his boss said, "I want Gaim to support reading RSS feeds. Make it happen." Laager explains, "My response as a Gaim developer is, ’That’s a stupid idea. Gaim is an IM client. If you want an RSS reader, go get one. Gaim will never have this feature in the core.’ But clearly, that type of response might not be acceptable as an employee." A savvy manager will think about these potential conflicts before they arise.
Some companies may create a block of functionality that they assume the open-source community will adopt with open arms. That may not be the case. As Laager describes it, "The manager needs to realize that their employer-employee relationship with the developer does not result in any power on the open-source side of the fence. They have every right to control what their employee works on at work (when they’re being paid), but they can’t order their employee to commit things upstream, for example."
Balance Work and Open-Source Identities
It seems like a trivial issue: When a developer participates in an open-source project, should he use a personal e-mail ID or a company ID? However, the distinction can be an important one. On one hand, your legal staff will be concerned about whether and how the employee represents the company identity in public, and what information is shared. But there’s also the personal issue of the employee’s life and his ability—and arguable need—to create distance between work relationships and open-source participation. And some developers use a personal e-mail ID just to avoid the boilerplate legal disclaimer ("This is privileged private communication...") some companies slap on the bottom of every e-mail message; no open-source community wants the appearance that any of the development is private.
Despite your legal department worries, the reality is that everyone will recognize the developer no matter what ID he uses. Explains Tom Callway, head of marketing at Sirius, "Developers who are heavily involved in an enterprise-class OSS project (Samba, Postgres, Linux kernel, etc.) will almost always be known to their peers, as will their employment background. Without this transparency, they just won’t be taken seriously enough for their code to be accepted into the main development tree."
The harder issue for you as a manager is helping your developer find a balance between her personal, professional and corporate identities. Says Leach, "Open-source identity is a harder one to solve, and to be honest, it’s one I struggle with all the time. Corporate versus open source is easier; you can always keep e-mail addresses separate, or even use a different name. (This becomes a bit of a problem when you start wanting to go to conferences!)" But generally, she advises, developers should just think about what they’re writing, act professionally on mailing lists and remember they’re representing the company.
It’s harder to balance the personal with the professional, Leach cautions. "If you make a bit of noise in the open-source world, people will do a Google search on your name, find your personal website and read it. I have just had to accept that I have to censor myself on the Internet. Everywhere."