Open-Source FAQ
See our Open Source policy for more guidance on how we create and use open source software.
What is ‘Open-Source’?
A piece of software is ‘Open Source’ if anyone on the internet can access it, copy it, use it, suggest modifications to it, and redistribute it. Open-sourcing a piece of software is the process of publishing a piece publicly, including an open source license that grants permission for anyone to use it, and shields the author from any liability incurred by the use of the software.
Open-Source content isn’t limited to software, there are projects for Open-Sourced scientific publishing, Open-Source data, and even Open-Source architectural plans. The general principles are the same across these ideas: everyone benefits when information is more freely available and useful.
For more resources and a more official definition of “Open Source”, check out the Open Source Initiative’s FAQ page. They also have a list of popular open source licenses.
Why do we want to open-source parts of the code we write?
There are plenty of reasons why open-sourcing can make sense for a project, Google has published a broad list of possible reasons. For Silicon Ally in particular, we have a few motivations.
Increasing impact
Building a high-quality piece of code can take a lot of time between writing the code itself, testing it, and writing documentation for how to use it. By doing this work once and sharing it into the broader software community, we allow people to save time they’d otherwise spend re-implementing things that already exist. Instead of a generally useful piece of code being limited to a single project, it can potentially be reused in thousands.
Giving back to the community
We rely heavily on open source software for everything we do, from our workstation operating systems and developer tools, to libraries used throughout our frontend and backend software, to parts of the cloud environment where everything ends up running. We directly use hundreds of open source tools in building software for our clients, and indirectly use tens of thousands of pieces of open source code. This software is given to us free of charge and with no expectations of how we’ll use it. Doing the same when we can is a way to pay forward the generosity of past development on which we’re acutely reliant.
Attracting interest
Publishing high-quality open source software is a way to demonstrate to potential clients, donors, and prospective employees the quality of our work and the value of our services. As a software engineering organization, it’s one of the easiest and most powerful ways we can market ourselves, meaning we can spend more time working for clients, and less time finding work, attracting talent, and seeking donations.
Receiving external contributions
Once the code is open source, external contributors can use the code for their purposes, and can suggest changes to improve it. This includes new features, general improvements, and bug fixes. In this way, the community can help improve the software that we’ve open sourced.
What are the downsides to open source?
Competition
One downside to building your code as Open-Source is that it makes it easier for folks who want to compete with your product or project to replicate it. This is one of the core reasons that we will only suggest open-sourcing pieces of code that are use case agnostic, or can be applied to a broad range of potential issues. We’re not interested in open-sourcing code that is tightly coupled to a client’s use case.
Time
Building open source software takes comparatively more time than building a closed-source system. This overhead is probably 10-20% of the time to build the software. Most of this time is spent critically thinking about how to robustly test and document the software, and how to make it reusable for other purposes. This overhead is actually a good thing, because though it may take a little more time, the software generated through this type of scrutiny tends to require less maintenance, have better reliability characteristics, and be easier for future engineers to work on.
External Visibility
When an organization open-sources its code, it is giving the external world clues about how it operates internally. If it open-sources all of its code, this constitutes a roadmap for how the service works, and might present a security or operational risk. The good news is that we’re cognizant of this risk in thinking about what we want to open source from our projects, and will only recommend pieces of code to open-source that don’t leak sensitive or potentially revealing operational information. Beyond that, we also employ security best practices, like the principle of least privilege and defense in depth, such that knowledge of our internal structure is unlikely to result in compromise on its own.
Licensing
The code we write for clients is (by default) exclusively licensed to them. When we open source a piece of code, we’re actually creating a different project, which will have a different license. This means the client is no longer the owner of that piece of code. Though this sounds scary, the effect of this distinction isn’t meaningful - clients retain indefinite, perpetually free access to the code, and the upside is that they’ll continue to get updates to that piece of code without paying for them.
Clients are in control.
Rather than proactively open-sourcing the code we build for clients, we will build it to be capable of being open-sourced, and request client approval prior to actually publishing what we’ve written. We never open source client code without their permission. This enables us to have a candid and specific conversation about the possible benefits and risks of open-sourcing in the context of specific pieces of code.