Pros and cons of a DIY approach to contributing to open source efforts

The open source celebrity

Why would anyone be contributing to open source? For an individual, there's a glory factor, and that goes for companies, too, Ward said. Open source code is a tool or an application that boosts visibility and shows leadership in an industry. It can also lead to achieving a guru status and a successful work life, as the career of Linux creator Linus Torvalds demonstrates.

For vendors, open sourcing helps build trust with customers and partners by ensuring that that code will remain available and open to improvements by a community. Also, open sourcing can help create an ecosystem around a library and tool or framework. Ward noted that open sourcing gives businesses a new recruitment pool, which is ideal for candidates who contribute to that project. In these days of developer shortages, that's a big plus. "It is hard to find developers," Ward said. "When someone adds to [Salesforce's] project, HR can go to recruit them."

Open sourcing = risky business?

There are legal, security and quality risks in making open source contributions, Ward said. Here are just a few that he mentioned in his session:

• Be careful that you're not publishing your sensitive data. "There may be connects that you don't see that could be in your [code's] history," he warned. "Are you making something public that [could be] embarrassing, or worse, libelous or a security risk?"
• On the quality side, make sure your contribution really works and it isn't a poor cousin to another product. "If I publish my product externally, I open myself to judgment and criticism," he said.
• Be sure that you have the resources to maintain a release and external contributions to it. That maintenance must include investigation into whether contributing to open source projects infringes on an intellectual property of another project or product.
• Cover all bases in security, because your contribution could be a hacker's gateway to an entire project.
• Be able to prove who owns a contribution. "The gray area with projects is that most people [who are] creating code work for a company," Ward said. A big question is: "Did the developer create his own code on his own time or on company time using a company computer?"
• Businesses contributing to open source have stringent due diligence on patents and are clear on ownership issues. Make sure that licenses are in compliance with corporate standards.
• Can you handle governance and compliance? "Most projects don't have governance," Ward said. Or, he said, governance is done on an ad hoc basis by contributors. Do-nothing governance can work out well. If problems arise, you can run into "a lot of gray area in the governance systems." The choices then are hard when there's governance foundation.

Many developers avoid these and other management issues by doing nothing about them. In particular, they don't want to get their company's legal team involved. "Legal wants to mitigate all concerns," and that takes a lot of time, Ward explained. So, developers cross their fingers and hope that nothing goes wrong. "It can be better to ask for forgiveness than to ask permission. If you ask the lawyers, you open a can of worms."

On the other hand, there are good reasons for consulting legal; one being when license issues are a gray area.

Using foundations like Apache and Eclipse

Rather than taking the risk of DIY open sourcing, developers can sign on with non-profit open source foundations and organizations that provide support for free software projects. These include Apache Software Foundation, Eclipse Foundation, Free Software Foundation, Linux Foundation and many others.

These open source organizations provide "a lot of infrastructure out of the box" to deal with security, governance, legal, quality and other issues, Ward said. Often, they offer financial support to projects. Overall, they help limit legal ramifications of contributing to open source projects.

Credibility is the biggest benefit of using a foundation. A foundation provides a safety net and shows that a project is not at the whim of an originator. "Some customers won't use a technology unless it is open sourced to a foundation,"  he added.

The downside of using foundations is that there are rules and standards. "Governance can be heavy. You have signed up to manage your open source project in a certain way and must conform to requirements of the foundation. It's a signal of project maturity," he said.

Ceding ownership of a code to a foundation -- almost always a requirement -- can be a negative for individual and business contributors.

"Lawyers may not be happy with [a foundation] taking the company's intellectual property," he said. "If you want to see something fun, watch lawyers scrutinize code."

Creators of a code have some usage rights in the foundation framework, but there are many limitations. "Using a foundation is a good way to lose great engineers," Ward warned.

Build when you can't buy?

Building your own (BYO) open source project management system is an alternative to do-nothing or foundation approaches. GitHub provides a foundation for BYO projects, including many APIs for tools that target management processes, according to Ward. Of course, there's a lot of work involved in building and maintaining that system. Also, collaboration tools like Atlassian can provide automated communication for a project. There's not much help with legal matters, however.

Don't expect to find a hardy off-the-shelf OS management tool set, as few exist, Ward said. He's working in GitHub on some project management for Salesforce. Will he open source it? He hopes so, but that depends on many issues.