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

One of your developers wants to extend an open-source application to solve a company problem, then contribute the code back to the community. That’s fine. But making that process work in enterprise terms involves more than getting the legal department to recover from its fainting fit.

1 2 Page 2
Page 2 of 2

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

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams