The Enterprise Committer: When Your Employee Develops Open-Source Code on the Company Payroll

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.”

Farrukh Najmi, CEO of Wellfleet Software and principal architect for the freebXML Registry open-source project, admits that the needs of the open-source community can occasionally present a conflict with one’s company identity—or at least veer in that direction. “I was building a Sun product, such as Sun Service Registry, based on an OS project like freebXML Registry. This is a similar model as Red Hat Linux and Linux. I was also leading both projects. This meant that I had to delicately balance the interests of the OS project against the Sun product. I developed a model that I called Open, Collaborative, Community-driven Development. On occasion, the interests of Sun Management and the OS project collided. In such, there was no actual conflict but more a case of Sun Management making faulty assumptions and requirements. In these cases, I did what I felt was the right thing (and asked forgiveness later).”

Technical Issues? What Technical Issues?

Few of the open-source developers raised any technical issues among their frustrations. One of the few exceptions was the issue of how to track bugs: Do you use the company tools or the open-source community’s libraries? Najmi says, “In my case, Sun tracked their bugs in the Sun Bug Tracking tool but made it visible to anyone outside the company. At the same time, the OS project did its own bug tracking—but since more bugs were found by Sun’s team, more bugs were entered in Sun’s Bug Tracking tool. This is a tricky issue. I suggest using the open-source project’s bug tracker exclusively, if possible.”

David Webber is an XML consultant and OASIS member developing public XML standards for use in open source. Involved in several open-source projects (including JCam and freebXML), he adds that there are open-source tools for setting up sourceforge CVS facilities and installing CVS servers. “Tortoise CVS is one such,” he suggests.

The sticky issues are, of course, all about people. For most developers, participating in an open-source project is a positive statement about themselves personally and about the company for which they work. Managers should respond accordingly when they set expectations. “At Myxa, it was a point of pride to have your project extended for open-source contribution,” Weinstein says. “The developer was expected to meet their milestones, and the open-source part became part of the code they developed for our applications. We always found a way to tie them together, and everyone chipped in on testing, et al.”

But managers also should understand how open source is different from regular development, Najmi advises. This may cause minor disruption to the way your existing application development department works. In open-source projects, team members never meet. They rarely have teleconferences (though some teams use IP telephony such as Skype); they’re more likely to rely on Instant Messenger heavily, so companies can’t block or discourage its use. Open-source developers typically use universal IM clients (such as Gaim, Trillian or Kopete) and have accounts with many services (AIM, MSN, Yahoo, Skype, IRC, etc.). Najmi says, “Team members may work odd hours to sync with team members in other time zones. Often, they work 16-hour days. Be flexible about comp time, so they can work hard when needed and relax when the timing is right.”

Najmi stresses that, because the employee will be working independently, the individual needs to be self motivated, dedicated, passionate about the work and above all honest. If that’s the case, “Give them the opportunity and give it with lots of trust and freedom. Do not micromanage. Instead, be results-driven; set goals for them to achieve, and then measure results against the goals.”

Measuring your employee’s performance is one thing, but you also need to be aware that she’s representing the company to the outside world. Leach says, “I cannot stress enough mailing list conduct. If you have a team working on a project, perhaps identify one person as the contact with the community initially, until the rest of the team learns the best ways to interact with the community. If they show signs of wanting to be one of those people who are rude and snarky on mailing lists, nip it in the bud really quick.”

Know the OS project, Najmi says. Make sure that it is well governed, has a good, healthy community, and good team processes and discipline. “You do not want to contribute to a project that is running amok,” he points out. Look at the user and dev list traffic for the project. Make sure there is enough traffic to indicate a live healthy project; the team should be effective and collegial and handle technical disputes maturely. The manager should also examine the project’s website, online docs, wiki, FAQ, etc., to judge the project’s maturity.

The manager’s decision to say, “Go ahead and work on Foobar for 20 hours a week” is not one that should be made lightly. For any enterprise, the involvement in an open-source project is a commitment. Says Grieve, “It’s not quite so easy as, ’We’ll let you work on it,’ because once an employee starts working on a project, it’s not easy to pull back, or to re-redeploy them.” Before you make the commitment, he advises, know what the benefits are, in both directions, and determine how you’ll measure them in your cost-benefit analysis. This is difficult because some of the benefits are intangible—but very substantial, Grieve advises. “I’ve come to regard a company’s ability to commit to open-source projects in an enduring sensible fashion as one of the best markers of the quality of its management,” he says. “And judging by what I’ve heard, this is starting to become a criteria for prospective employees.”