Frequently, we're asked by our clients and others agencies and developers why we choose Open Source Software (OSS) and technologies over some of the proprietary options available in their respective spaces.
For example, we're strong believers in the Drupal content management system, it's associated ecosystem as well as frameworks such as Ruby on Rails and Laravel and their Open Source languages, Ruby and PHP (respectively).
While we field these questions in passing, we felt it was time to elaborate on our rationale. The answers are fundamental to what we do as an digital workshop and how we best serve our clients. These considerations can also help guide others who are considering this path, or encountering challenges.
To start, it's probably a good idea to describe what Open Source Software is (OSS) and how it differs from it's more proprietary options.
What is Open Source?
Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose. Open-source software may be developed in a collaborative public manner. Open-source software is the most prominent example of open-source development.
Meaning, with the right skills and resources, someone can take the source code for a web site, application etc. and run, alter, and possibly re-distribute the deritative work. This may sound difficult, but many, many services exist to facilitate this distribution and large communities of developers support and contribute regularly with this goal as their sole reason.
For us, being able to review and analyze the code for projects that we are evaluating is an important step for determining the overall quality of a potential tool to add to our toolbox. This allows us to support our clients by developing or delivering better solutions built on these tools.
Now that we have a better understanding of OSS, there are 4 distinct reasons for our preferences:
To get straight to the heart of the matter, Open Source Software (OSS) can be much, much less expensive than it's proprietary options. This really is no surprise at all. You don't typically have to pay to use OSS and with full access to the source code you can install, configure and augment it (if the license is permitting, more on that later) at will (again, license permitting) without paying a single cent to the originators of the software or technology.
Not everyone will recognize the cost benefits of OSS unless you have the resources to understand it and support it. We're in a lucky position (as it is our day jobs) to use this software every day, support it, contribute and maintain what we use, so we are familiar with the foundation and / or constituent parts of these toolsets.
Often, a crucial component of our decision making when evaluating OSS is whether there are support options available that we can rely on if needed (which, is very rare), or that our clients can rely on to reduce any vendor lock-in, even to us as a vendor.
Software, applications, and projects differ greatly in their complexity and supportability. One significant advantage to OSS is that there is no need for potentially expensive Escrow agreements between vendors and customers. These agreements ensure that the customers will have full access to the source code in the event that the vendor decides - or is unable - to support their software, or specific version of their software any longer.
The bottom line is that OSS allows us to reduce our own costs through avoiding spending money on licensing/support (if applicable) which is cost savings that are passed on to our clients.
We're an Agile workshop in more ways than one. We also prefer our toolset to be agile and - with proprietary tools or technologies - we would be "vendor-locked" to the features and functionality that these tools provide. Our clients ask, and have come to expect, that we're not in the "boilerplate" business and without the ability to push the technologies we use and employ, we would be less effective at what we do.
In the proprietary software space, we are tied to any one specific vendor. It would pin the success of our projects and, more importantly, our client relationships on the whims of companies or individuals outside our sphere of influence. This is not a risk that we would take lightly, nor would we benefit if the purchase of an application or tool meant that we would be incentivized to find ways to use it, even if it may not be the right tool for the job.
There are no black boxes in the OSS space or, better yet, with full access to the code that makes these tools tick we can dive in and fully understand and appreciate what the software is doing.
Aside from cost, the licensing within OSS is important to mention. There are a wide variety of licenses available for project/software maintainers to choose from, and many of them have their benefits and drawbacks. The linked article is a great introduction to these license types, so I will not cover them at length here.
However, purchasing a license vs. license selection are two distinctly different considerations when selecting or evaluating OSS. Most software covered under these licenses is distributed for free, but the license stipulations for altering the code, redistribution, attribution, indemnity etc. differ slightly or widely between the available options.
In our case, if we are looking to alter any of the existing code of a particular project or application, careful consideration of their license is important to determine that the correct attribution(s) are in place, that we include the correct licensing details with the redistributions, or whether redistribution is allowed at all.
We evaluate the licenses of the OSS projects we use carefully, as well as the licenses that we choose to use when releasing projects/code of our own.
Finally, and likely the most important consideration when evaluating OSS is the community. It is our responsibility, given that we benefit from these communities, that we should also be active participants.
When a particular technology is popular within the development community, options typically explode for not only extending the functionality of these tools (provided the facility exists to do so responsibly) but also the mindshare of what is possible or problematic grows expontenially.
Selecting a piece of OSS that is not particularly active in terms of development or interest can be risky if resources are not available to understand the software and its implementation let alone support, maintain, or extend it.
Particular standouts for us when it comes to community are Ruby on Rails and Ruby, Laravel and PHP, React, Drupal/Wordpress, Ionic and relative newcomers to the OSS game .Net. There are many, many more excellent examples of OSS communities that are not only expansive, diverse and supportive, but contain some of the smartest people and ideas that are the forefront of the technology and web space today.
It is easy to look at free software and say that that is the most substantive benefit to adopting it. However, cost alone is not a good way to evaluate Open Source Software (OSS). Careful vetting of licensing, community, support options and your own ability to support these technology decisions are key when evaluating OSS. Adopting an OSS framework, language, or application should be carefully considered against these criteria to better position projects that rely on these tools for success.
Choosing an OSS technology solely on one or two of these criteria, without the adequate resourcing to support it, will almost certainly lead to difficulties later on.
OSS allows us to be agile in that we're not tied to a specific vendor or vendors, applications or tools and we can adopt the best-in-class available options when it's clear that they're the best match for our client needs. If the situation arises when an OSS tool doesn't 100% fit the bill, with full access to the underlying source code of these solutions, we can also fully understand and/or augment these tools to ensure that they're meeting the needs of the project.
Being aware of the commonly used licenses in OSS is incredibly important when considering how the software will be used. It's an issue of respect to the values of the community that the initiators, maintainers, and supporters that are providing these tools are respected, and their wishes (expressed through license usage) are followed.
The importance of community in OSS could not be overstated. The successful OSS projects are supported by both the developer and non-developer communities and, as stated, it is a crucial component to our evaluation process. The stewardship, support and respect of these communities is essential to maintaining and ensuring the quality of what they provide. It is the responsibility of companies like ours to support, contribute and ensure that these contributions are valued.
Finally, we value OSS so much that we've decided to release the core of Wicket - our member data management platform - as open source. In the coming weeks and months we'll have a lot more details about what this means, how it can be used, and our goals for choosing this path.
Interested in learning more about Open Source Software and how it can help your organization? Drop us a line, coffee's on us.