Feature

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.

PAGE 5

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