The Open Source Value Proposition

Every so often, advocates and vendors of proprietary/closed source software attempt a FUD (Fear, Uncertainty & Doubt) campaign of comment and link-baiting in order to reframe the conversation around Open Source. The arguments brought up in these discussions are predictable and generally straw man arguments that hold little water, so I wanted to take time to break these down and show the real value proposition of Open Source platforms, web content management systems generally, and Drupal specifically.

Free From Costs, Free From Constraints:

In order to have a cogent discussion about Open Source vs Proprietary, we have to set the appropriate stage. Much has been made about how Open Source code is “free” from a financial perspective, and although this is certainly a selling point, it’s actually a side effect of the actual meaning. Open Source, and more importantly the GPL (GNU General Public License), aren’t just free, as in dollars, they’re free as in freedom. The promise of the GPL is that a consumer has the opportunity to know exactly what code they are running and what that code does. In practice, we all recognize that the average consumer is unlikely to inspect the code they’re running, but the practicality of the situation is actually less relevant than the principle being followed. The fiscal aspect of Open Source code is really just a by-product of this principled adoption of freedom. This adoption of freedom is there to protect the consumer, not the developer.

Code is code:

Having established this central point around the freedoms associated with Open Source, let’s talk about the actual code. Code is code. I know that might seem obvious, but far too often proprietary FUD relies on arguments that proprietary code is somehow fundamentally different from Open Source. This is not the case. What is different is the number of people the average proprietary CMS has working on its code base. How many developers can be employed by one company to work on their proprietary solution? The question is somewhat rhetorical -- regardless of the actual number, a business can only afford to employ so many people, even for their product development. Any business is still limited by their revenue. Marketing and sales fill the pipeline and bring in the money and contracts upon which developers deliver. Often, those contracts split developers’ time between the core platform and delivering on the custom needs of their clients. Open Source solutions are not so constrained. The developers involved can include both those funded by their employer and those who work on their own time all for the betterment of the platform. This expands the developer pool dramatically, and also increases the likelihood that an Open Source solution is going to have code for any given use case. With so many parties involved, the diversity of needs tends to generate solutions, and this is something that benefits the whole community.

Proudly Found Elsewhere:

Open Source solutions also have an opportunity to leverage code from other Open Source projects. In Drupal’s case, as of Drupal 8, we’ve adopted the wildly popular and heavily used PHP components for formulating HTTP requests (Guzzle) and building a REST first routing solution (Symfony) just to name a few. Sharing code libraries of this sort compounds the benefits of Open Source by aligning developers from diverse groups on similar trajectories, bringing the benefits of many well tested, widely implemented components together as a cohesive whole. Proprietary vendors don’t quite have an equivalent of this. Sometimes you find solutions that have purchased pre-existing components from other vendors, but this separates their developers from their code base, increases internal support costs and literally adds to the cost of “their” solution. Freedom begets freedom, and in this case Open Source’s freedoms allow it to share code across diverse projects to build cohesive solutions.

The Drop is Always Moving:

This is kind of the unofficial slogan of Drupal, but it’s true of the web in general, and in this case, what’s true for the web is true of Open Source. This is a critical point because it returns the conversation to one of resources. If, as a proprietary vendor, you are busy building your product, you can only have a limited scope of features that can be included. This is true of Open Source solutions as well, but Open Source benefits from an army of volunteers constantly keeping the system up to date with the newest web technologies and trends. Was a new API released today? Check back tomorrow, there might already be a module (or PHP Component) for that. Only Open Source can offer such an insane adoption schedule.

Security is not a Secret:

Proprietary vendors like to tout their security, but an absence of security record is a lie by omission. Others have covered this topic before (Thanks Nate!), but Open Source has a greater shot at being secure than proprietary code. This is an undeniable truism of the industry and while we’re at it, here’s another you won’t often hear: No system is 100% secure. Open Source allows for developers (many thousands of them) to not only find and fix bugs of all kinds (including security) but also in a well developed project you will find a security team who is dedicated to helping find fixes for security problems and providing proper responsible disclosure to the public at large in order to keep the greatest number of installs secure and up to date. An open security model is built on the same sort of trust model the GPL provides for the code base at large. The model is open in order to encourage adoption of more secure code bases, it exposes the extent of security threats and it provides solutions to compromised consumers. Again, the average consumer is unlikely to be technical enough to truly understand this, but that doesn’t mean that they don’t benefit from it, and it’s part of why having an Open Source vendor is a big deal.

Bulletproofing Your Experience:

The growth of commercial Open Source companies provides consumers with a bullet proof solution for their Open Source endeavours. Partnering with an Open Source vendor, while not a requirement, shortcuts your time to market, and places at your disposal vital resources with the knowledge to get the most out of your solution immediately. At Acquia, we have worked hard to build products and services that naturally pair with the Open Source content management framework, Drupal, so we know a thing or two about Open Source and how to be the best sort of Vendor. The pace of ongoing development of Drupal (and other Open Source solutions) is faster and more agile than what is possible from our commercial counterparts. This means new capabilities are being built, tested and delivered more quickly and efficiently than among commercial systems.

The community of vendors and individuals that has coalesced around Open Source platforms like Drupal means a massive, highly engaged set of professional developers working together to bring about improvements to the core platform and critical contrib. The ranks of Open Source developers have grown to a point where proprietary platforms are falling behind, and the gap will only get larger. All of this has flipped the prevailing question from “Why Open Source?” to “Why not?”

I’m Kris Vanderwater, Drupal developer and Acquia's Developer Evangelist. My job is to help you – the developer – get the most out of Drupal and Acquia’s products and services. If you ever have questions, comments, or concerns, reach out to me any time. I've included some ways to contact me below.

Google+: Kris Vanderwater
LinkedIn: Kris Vanderwater
Twitter: @EclipseGc
IRC: EclipseGc

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.