We all rely on free, libre, and open source software (FLOSS), whether we know it or not. It’s on your phone, your router, your car, the Large Hadron Collider, super computers, satellites, smartwatches, the server delivering this blog post, and the browser you’re using to read it. It’s everywhere.
Salesforce is no exception. At Salesforce, open source allows us to build trusted products and services faster. Rather than reinventing the wheel, we can use pre-existing software built in the open by people and companies who have already run into the problems we need to solve.
We could stop there: simply be a consumer of open source and diligently comply with what the licenses require of us. But these days, open source consumption and compliance is just business as usual.
There’s a lot more to open source, and as with most things in life, the more you give, the more you get. In the spirit of open source and in the interest of good business, I present to you: open source citizenship.
What is open source citizenship?
Borrowing from the broader concept of citizenship, being an open source citizen means recognizing we’re part of a larger ecosystem that grants us both rights and privileges, as well as responsibilities.
Being an open source citizen means taking bug fixes and new features we make and contributing them back to the open source projects. It means providing resources that the project communities need, including financial support and event space for summits, sprints, and meetups. It also means participating in technical decision making, and helping to shoulder the weight of triaging issues and pull requests, even when it’s not directly related to our own needs.
Because ultimately, it’s that kind of participation that keeps communities healthy. And healthy communities translate into greater productivity, innovation, stability, and better security.
Where is Salesforce at in its journey?
Going from consumer to citizen is a process; every company goes through a journey with open source.
Companies often begin as (sometimes unwitting) consumers of open source. At some point, they formalize their processes and policies for inbound open source. Later, they formalize the processes for releasing their own software under open source licenses. Eventually, they become active contributors, and some go on to use open source strategically to do things like encourage the adoption of a standard.
Salesforce, founded in 1999, the year after the term “open source” was coined, has long been a consumer of open source. Sometimes organically, like when our developers started using Ubuntu instead of Windows. And often intentionally, such as when we decided to build our core platform with Java on JDK.
As Salesforce began using more and more open source projects, we’d occasionally find bugs or run into limitations, which we’d then fix and upstream. For instance, we ran into performance issues with Apache Qpid, found a way to reduce memory usage by 40%, and then shared that fix.
Eventually, we’d go on to release in-house projects under open source licenses: like Apache PredictionIO and Apache Phoenix. The latter was built as a way to query Apache HBase (a NoSQL database) with SQL queries, it was open sourced in 2012, became an Apache Incubator project in 2013, and graduated to become a top-level project of the Apache Software Foundation in 2014.
These days, open source is practically ubiquitous inside Salesforce. We’re active contributors to hundreds of projects, we sponsor many events and foundations, we’re mentoring student developers, and we’re working with other companies through the TODO Group to advance the state of corporate open source engagement for everyone.
We’ve come a long way, but there’s still work to do.
While we’ve developed policies and processes for using and releasing open source software, they’re far from perfect and can be a bottleneck. While we sponsor lots of events and foundations, there are many more that we need to support. While we contribute back, there are more ways we should be contributing.
And while we’re doing a lot already, we can be doing a lot more: in a company as large as Salesforce, knowledge and experience with open source can vary widely between teams. That’s where internal outreach comes in — and it’s not enough to have people know how to contribute, they also have to know they’re encouraged to do so on a regular basis.
As we fine-tune our processes and expand our support of open source, that internal outreach is the engine that’ll drive greater participation in open source communities.
Knowing this, we should be able to get a little closer to modeling the kind of open source citizenship that protects and promotes open source for the benefit of all (while driving great results).
How can I help my company be a better open source citizen?
This is a subject that deserves an entire series of posts. In short, though, becoming a good open source citizen takes both a top-down and bottom-up approach. It requires support from leadership, from those who build the software, and everyone in between. But you’ve got to start somewhere!
I’m co-presenting about corporate open source citizenship with Googler and open source luminary Cat Allman at OSCON and Open Source Summit North America, the recordings of which you can find online afterwards. And you can bet I’ll be blogging more about it as my teammates and I help Salesforce along in its own journey.
No need to wait, though. You can start today by reading this article on 8 ways your company can support and sustain open source or the TODO Group’s open source program management guides.
