Need to create new solutions while increasing productivity and also saving time and money?
If you're a startup, you do -- but pulling all that off can seem almost impossible.
Here are Ian and Regina:
Startups are constantly looking to save money and increase productivity wherever possible-- but finding these efficiencies can be easier said than done.
One approach that has proved successful for many small businesses is to utilize open sourced platforms. Startups that are savvy in taking advantage of open source are able to harness the developments of a broader community to build on existing code and create customized solutions-- spending less time and money than they would crafting something from scratch.
However, many startups find themselves unsure of how to get started and feel bogged down by process.
The key to successfully adopting an open source approach is understanding how to balance the risks and rewards of participation, which relies on three pillars: showing the value, facing the risk and rallying your allies.
1. Showing the value.
Participating in open source can be a huge accelerant. It's a healthy form of transparency that can transform a software project from a local effort to a global collaboration. That doesn't always happen--nor is open source right for every project--but when it works, it carries a host of benefits for the team, software and the company.
To understand why, think about a simple task like sorting a list. Coders traditionally had two choices: build it or reuse it. Open source provides a third choice: share it. Coders can find a project that almost meets their needs, and invest in it by adding features and fixing bugs.
This approach extends beyond trivial sort functions, of course. Open source has proven successful with projects as big as operating systems, web servers and databases. As the line between "differentiating" and "commodity" moves its way up the stack, maintaining custom software that is no longer a differentiator can become a millstone around a company's neck.
When companies instead use and contribute to open source, they get the benefits of quality software, but also share the development and maintenance costs among many participants. That means they can focus more on the things that actually differentiate their business. They can also experience the other benefits of open source participation, like engineer enthusiasm, reduced vendor dependency, and improvements in code quality and security.
Open source participation doesn't mean that a company has to give away the "crown jewels." There will always be information above the "line of differentiation," where your company provides unique value through software. These days, many SaaS companies are following a "closed core" model--to use Andy Oram's phrase--where the company keeps the key money-makers proprietary, but collaborates on the parts of the stack that have proven to work better as commodities.
2. Facing the risk.
When a company decides to participate in open source software, that's just the beginning. Along with the benefits, there are real risks to consider.
The solution? Make the risks explicit, and face them head-on. That helps you avoid the real existential threats, without sweating the small stuff. A few areas you should consider:
- Licensing: Not all open source licenses are the same. While they all give anyone the right to study, change and distribute the software, some make additional restrictions. For example, some (like GPL, the GNU Public License) require developers to make their own modifications to the source code available as well. The GPL license goes even further, in fact-software that incorporates GPL code may only be shared with others under the same license, which means in some cases it could even extend to things you weren't intending to open source.
- Intellectual Property: Releasing open source means, by definition, that you're giving up some intellectual property rights. But, the boundaries of this aren't always clear; if you have a patent portfolio, even if you intend to use it only defensively, you must understand the effect the licenses will have on that portfolio. And when you accept contributions from outside sources, you need legal assurances they actually owned the copyright in the first place, which is where a Contributor License Agreement (CLA) comes in. Making sure legal is involved can keep you aligned and within the Intellectual Property boundaries your company feels comfortable with.
- Security: For most companies, security is a prime directive. So when you disclose code as open source, it's critical to ensure that you're not also disclosing undetected weaknesses at the same time. In the long run, open source participation makes code far more secure (because there are so many eyes on the code--security through visibility, not obscurity). But on a day-to-day basis, it takes ongoing work to review and identify security issues quickly, so partnering with security teams is crucial.
- Strategy: Finding the line between code that is "differentiating" versus "commodity" takes a very high-level perspective--typically from an executive (since individual engineers can be so immersed in their own code, it may be hard to keep the big picture in mind). It's important to identify these key supporters who can highlight where contributing to open source is a strategic, proactive and intentional decision.
All of these risks can be understood and conquered, but in a big company, it takes a village to do so. That's why the third pillar is crucial.
3. Rallying your allies.
The key to balancing risk and value is to bring everyone into the conversation--to expand the company's perspective to include the whole picture.
An important early set of allies are executives. Depending on their background, they may or may not "get it" when engineers talk about open source with stars in their eyes, but they certainly grasp the risks, and can be big blockers if you're not transparent with the pros and cons.
The most unlikely--and essential--group to make an alliance with is the legal department. Legal faces down most of the risks, and it's only when your engineering team understands those risks that they can make progress. Take time to understand their needs (versus complaining about how long approvals take). Work with them to set up lower-friction ways of interacting, like explicit "green light" categorization for low-risk projects, and explicit guidelines for teams. These small steps make a big difference for teams that are actively engaged in open source contribution on a daily basis.
Ultimately, the biggest allies you'll have for open source are engineers. They're the ones whose code is "going public" in this process. Engineers find pride in open sourcing their work and can help improve the process over time, as long as you help them understand the full picture of risks and rewards as well.
Creating a culture of transparency in an engineering organization is a long process, and even with support from the top, it takes time for things to come to fruition.
Plant the seeds now for contributions that will grow in weeks, months or years.