Tips for Evaluating a Company's Open Source Culture

There are four essential questions a company should ask before it decides to create an open source project, according to Duane O’Brien, open source programs evangelist at PayPal.

  • Who cares?

  • Are we still using it?

  • Are we committing our own resources?

  • Can we develop it all in the open?

This framework, developed by O’Brien’s boss Danese Cooper, is useful in vetting internal software for release as open source projects.

In a nutshell, a company shouldn’t open source software that no one else cares about, that they themselves are not using, that they will not commit developer resources to maintaining, or that they continue to develop in secret without community inclusion. (You can see more details and the rationale behind each question in his blog post on OpenSource.com earlier this year.)

“If no one contributes it becomes unmaintained abandonware – a pollutant in the open source ecosystem,” O’Brien said in his talk on the four questions at LinuxCon Europe yesterday.

But what if the answers to these questions are consistently “no?” This is itself a litmus test for a company’s open source knowledge and culture.  

“Use these questions as pointers about what’s going on in the company,” O’Brien said.

1. Who cares?

“If you’re consistently getting: “no one cares,” it’s a good indicator that your technical community isn’t very well connected to the industry,” O’Brien said.  Open source advocates within a company should consider engaging in programs that encourage engineers to join communities and technical discussions. Some examples are:

  • start publishing a podcast

  • start publishing blog posts

  • encourage employees to attend meetups and talks

  • provide travel stipends for employees to attend conferences

  • bring outside experts in to give talks.

2. Are we still using it?

If a company only open sources projects they’re not using anymore, that’s bad corporate practice, O’Brien said. It damages that company’s reputation in the open source community.  

Instead, he recommends looking for what has replaced that defunct code and consider that as an open source contribution.

“Look for exciting things and mine them for open source projects,” he said.

3. Are we committing our own resources?

“If we aren’t committing resources, we’re probably pushing employees and engineers too hard,” O’Brien said. “They should never be asked to maintain open source projects on their own time.”

If a company never commits resources to open source, “it’s also probable that managers don’t understand what a healthy relationship with the open source community looks like,” he said.

More management training on the importance of open source software and how to best use it strategically may be beneficial.

4. Can we develop it all in the open?

And if code cannot be released publicly because developers don’t want anyone else to see it, you may have code quality issues. Or if they’re not willing to engage with the community, which is required to develop in the open, “then there are probably culture issues,” O’Brien said.

These issues can be addressed through employee training and improved code review processes.

Regardless of a company’s answers to the four questions, one of the best things they can do is share what they’ve learned with other developers and companies. It’s good source material for blog posts, white papers, and talks: what you tried, why it didn’t work, and what you’d do next time.

“So the people who come after us can see where we went wrong previously,” he said, and the entire industry can move forward.

/by