Sam Dean | 18 October 2017
Salesforce says one key to open source program success is to focus on good “on ramps” to your open source projects with great set up documentation and healthy forums.
Salesforce learned early on that open source projects stay healthy when they have a diverse community of stakeholders that have an interest in making the software succeed.
Apache Phoenix started at Salesforce as its own open source Phoenix project. But it didn’t find success until people from outside Salesforce also got invested and the project no longer depended on the needs and desires of one company. In a true community effort, people from other companies joined in and said, ‘this is useful for us and we want to contribute,’” says Ian Varley, a Software Architect at Salesforce who recently led the open source program there. In the end, this diverse community is what allowed it to become an Apache project and incorporate new features that the company’s own engineers could never have dreamed up.
Salesforce stays focused on this concept of cultivating diverse interests to use and participate in its projects. At the same time, it’s equally focused on aligning its internal stakeholders — from engineering to legal, marketing and PR — with its open source efforts.
Open source program goals at Salesforce
Salesforce has many priorities around open source. The company’s open source strategy keeps everyone aligned. The dedicated open source program team circulates internal documents to the company’s engineering team that provide strategic guidance and encourage the creation and use of open source. The documents provide the foundation for an open source culture and let the team know in no uncertain terms that the company’s leaders are fully behind the strategy.
Open source is increasingly a part of just about every software project in every company that’s out there. It stands to reason that every possible type of business model you can have with open source is going to come into being and try its hand in the market.
Salesforce is a Software-as-a-service vendor, and doesn’t release the end customer-facing products that it sells as open source. Instead, the engineering team focuses on open sourcing shared infrastructure components, libraries, and tools that other companies might find generally useful, as well as samples, and SDKs that are of benefit to their customers.
How Salesforce measures open source success
One goal of the company’s open source program is building its reputation among developers. Engineers who may not use Salesforce products will sometimes look at the company’s open source projects and say, “Hey, this company is really involved with some great stuff,” Varley said.
“Open source is a window for (external developers) to see the great engineering that’s going on inside of the company that they otherwise wouldn’t be able to.” – Ian Varley, Software Architect at Salesforce.
The open source program also focuses on expanding the communities that align behind the company’s own open source projects. The communities don’t just use their software, they also contribute to it. So they focus on creating “on ramps” to their projects such as a clear approval process for patches, improved documentation, healthy forums, and welcoming and responsive maintainers.
“We’ve succeeded when we have given people ways to get involved with our projects that don’t require them to have a PhD or to have been working in a similar area for 25 years. You need ways for them to get involved quickly,” Varley says.
Salesforce also measures its own success against the industry-wide success of open source. The more progress there is in open source, in all of its many dimensions, the better off everyone is because more open source means more progress in the industry as a whole. If Salesforce can raise the baseline of what is commodity software and what constitutes shared components that everybody can depend on, the whole industry benefits.
Example: Apache Phoenix
Apache Phoenix is an open source big data analytics platform that’s now part of the Apache Software Foundation. But when Phoenix started, it was just a project a couple of Salesforce engineers built for some specific internal use cases. But, before long, the small team realized that anybody could benefit from the project and its velocity would improve if the whole world was working on it. So he made the pitch to open source it and turn it into a community project.
Within the first year of creating the open source Phoenix project, the Salesforce engineers started getting significant contributions in functionality from two or three big companies that had found Phoenix and wanted to join the project. By opening the project up to outside use and contribution, the Phoenix project progressed far beyond what the original engineers would have been able to do on their own.
5 Key lessons for open source program managers
Looking back at his 4 years of experience managing open source at Salesforce, Varley has five key lessons for companies that may just be getting started with their own open source programs:
- Create a company-wide policy that strongly encourages the use and creation of open source internally.
- Recognize that a community can advance a project far beyond what can be achieved internally.
- Seek input on your open source program from many different types of stakeholders. Engineers should not be the only stakeholders—your legal team and executive management should also be directly involved, for example.
- Focus on good “on ramps” to your open source projects with great set up documentation and healthy forums.
- Recognize that open source success can drive industry-wide success and better products everywhere.
This article was produced in partnership with the TODO (Talk Openly Develop Openly) Group as part of the Open Source Guides for the Enterprise.