To Open Source or Not to Open Source: that is the question.

5/12/2017 | AARON EDWARDS

To Open Source or Not to Open Source: that is the question.
Aaron Edwards

Aaron Edwards | Senior Software Engineer | Bio

The decision of whether or not to integrate open source components into your application, or indeed to offer your application as an open source product itself must, at the end of the day, transcend the realm of rhetoric and philosophy. It must be based on the requirements of the product, the cost of the development and (listen carefully, managers) the sanity and satisfaction of the developers on the front lines.

Open source software.  Few topics in computer science are as charged with rhetoric and religion.  Bring up the issue in room full of developers or product managers, and you’re likely to cause a whirlwind of opinions and opposing philosophies.  You may want to open a window because it’s going to get hot in there.

Step outside of the meeting room, however, and the realities of integrating components, both commercial and open source, into your company’s commercial offerings takes on a whole new flavor: philosophical stances and ardent opinions give way to the practical constraints of developing good software.  Do the components work as advertised? How is the documentation?  What is the level of developer support?

The decision of whether or not to integrate open source components into your application, or indeed to offer your application as an open source product itself must, at the end of the day, transcend the realm of rhetoric and philosophy.  It must be based on the requirements of the product, the cost of the development and (listen carefully, managers) the sanity and satisfaction of the developers on the front lines.

What is Open Source?
Open source software has a nebulous definition at best: it is alternatively defined as “free1”  software, software whose source code is publicly available and modifiable, and software products that “embrace and celebrate principles of open exchange, collaborative participation, rapid prototyping, transparency, meritocracy, and community-oriented development.2

In college, I had the pleasure of seeing Richard Stallman speak.  Stallman, arguably the founder of open source software, was a chief architect of the GNU project3 in the early 80s.  If you wanted to pinpoint the birth of open source to a particular initiative, the GNU project would be a very safe bet.  Put simply, GNU was an attempt to create a “Unix-like operating system composed entirely of free software.”4  One could further simplify it as “Linux 1.0,” but then you’d find Stallman picketing in front of your door with a couple dozen other furry and socially awkward engineers.

While the GNU project itself could be labeled as a failure (they were unable to produce a reliable kernel, the core component of an operating system which manages code execution), it was a success on at least two fronts.  First, it successfully completed all sub-components of the OS except for the kernel, which Linus Torvalds stepped in and completed in 1991, resulting in the birth of Linux, the first modern, free operating system.

Secondly, and perhaps most importantly, it firmly established the social, legal and technological constructs that would transform hacker culture into a loosely organized, global ecosystem of developers and initiatives with a common purpose.

The GNU Public License (GPL), first codified in 1989, provided for the unlimited use, modification and distribution of the products it protected. In short, it said that anybody could download a project’s source code files, modify them and redistribute them free of charge, provided that the modified, redistributed versions contained the same freedoms for downstream consumers in its license terms.  You could charge a fee for your product, but you had to make its source code available.  In subsequent years, GPL spawned numerous alternative open-source licenses, including the Apache Public License, the Microsoft Public License, MIT, BSD and numerous others, several of them not requiring commercial consumers of open source components to provide their source code5.

This last point becomes more salient when dealing with web frameworks and components for your company’s commercial web offering.  Any decent-sized web application will typically utilize numerous third-party components, some proprietary and some open.  Water Sage, for example, uses several open-source components and libraries both on the front-end and on the back-end, including JQuery, Aurelia, momentJS, linqJS, Bootstrap, Newtonsoft, PostgreSQL and C3. It is incumbent on the developer and her manager to make sure that they are in compliance with any licenses for software components that they utilize6.  You may want to get the lawyers involved, as a misstep here could spell disaster for your organization and its offerings.

Evaluating Components Based on Merit
So one critical consideration when evaluating an open-source component is simply this: will I be allowed to sell my product if it uses or consumes this component?  Is this the only consideration?  Of course not, but it is a fundamental lynchpin as it has important existential implications for your company.  After that, all other considerations when evaluating a component, proprietary or open, must be made on the merits of the product itself.

I have to admit that for years I had a deep philosophical objection to open source software.  It went something like this:  for a component to be fully functional, reliable and well-supported, there has to be a commercial incentive to the makers of that component.  No group of hobbyists, regardless of their noble intentions, are going to be able to produce and support a component that can compete with a commercial product developed by a company whose very survival depends on the quality and reliability of that product.  You have to have some skin in the game.

Okay, so I was a jerk.  My deeply held philosophical belief at the time was incongruent with two empirical truths: (1) that open-source engineers are anything but hobbyists; they’re in fact extremely capable and devoted developers who care deeply about the product and place their professional reputations on the block for their contributions, and (2) that proprietary software is no less prone to bugs and other issues than open source offerings (in fact, some Windows bugs have persisted across multiple years and versions).

Part of my misguided philosophy was a sign of the times: in 2005 there were simply a lot fewer open source products out there, and much of the quality and support was not on the same level as the commercial sector.  Plus, Microsoft did an excellent job of marketing to the developer community, and I was securely onboard the train to Redmond.   All this has since changed.

The number of open source projects has been roughly doubling every 14 months7, with GitHub boasting over 19 million open source repositories in 20168.  Open source projects are now being sponsored by big players in the tech arena: Sun, Oracle, Google and Microsoft all sponsor open source projects.  The level of quality, documentation and support on these larger initiatives now rivals those of major proprietary products.  Moreover, any real or perceived gaps in quality and documentation can be filled by any good developer with the time and motivation to do so9.

So what criteria should one use for evaluating an open source or proprietary component?  I’ve already stated my three biggest criteria: quality, documentation and support.

The most fundamental question, after “will using this kill my business”, is “does the product work as advertised, consistently, across all intended uses and environments.”

I always start by testing the product myself.  For commercial software, there is usually an evaluation version you can download.  For open source products you typically just download them or clone a repository and go.    I test extensively, in either an automated or manual fashion, depending on the product.  If it’s a web component, I test in every browser I intend to support.

Then I start looking for previously reported bugs.  GitHub projects have an issue tracker associated with them, so you can start there.  Many commercial products have some kind of bug reporting service available on their websites.  Those products’ forums are also good grounds for digging up bugs.  The things I’m looking for include the total number of bugs and the severity of those bugs.  Also important is the responsiveness of the company or contributor community to those bugs.  Are they actually working to resolve those issues in subsequent releases, or are they just labeling them as “features” and stamping the Close Issue button?

It’s a common misconception that software engineers love learning new technologies.  We don’t.  What we love is building things: new things, cool things.  Every few years a new, improved technology emerges that allows us to build newer, cooler things, or to maintain our old things but in a new, easier way.  So then we reluctantly close our doors, put our heads down, and start to read documentation.
Now if that documentation sucks, if it has errors, provides source code examples that don’t compile, or if it’s just not written in a language that we can readily understand, then we start to get bummed.  When evaluating a component or product for our team, the quality of the documentation is always a huge consideration.

Support can mean a few things.  For a commercial product, do they provide any support packages, either included in the price of the product or with an optional support plan?  And what is the quality of that support?  Recently we had a mini-crisis with one of our vendors, and needed their support immediately.  Fortunately, we have a bunch of geniuses working here, because we fixed it ourselves and a week later the vendor’s tech support representative called me back.

Many open source products have commercial support available as well for a nominal fee.  However, with open source projects the level of support is often a function of the number of contributors to the project.  GitHub will tell you how many contributors a project has, as well as other useful statistics including the release history and the number of branches, all an indication of support potential.
If you’re going to get support from other members of the dev community, make sure it’s in a format that works for you.  I prefer forums or discussion boards, as mailing lists become cumbersome, and gitter and other real-time chat options lack any persistence.

When evaluating components for your software application, you should consider both commercial/proprietary products, as well as free and open source offerings.  Candidate components should be evaluated based on their own merits.  Any previously held positions and philosophical convictions need to be set aside, in preference to an empiric examination of the quality, documentation and support of the product in question.  Finally, when choosing open source components, make sure the license requirements are something you can live with.

Here at Water Sage, we have evaluated hundreds of candidate software components, both commercial and open source, and have successfully integrated both types into our software.  At times the selection process was challenging, due mainly to there being so many differing products to choose from, as well as our individual, personal convictions.  At the end of the day, however, this can’t be a philosophical decision.  You have to choose the right tool for the job, regardless of where the tool comes from.

In my next post, we’ll begin looking at a real-life case study of the challenges and benefits of one particular open source component that has become my new best friend: GeoServer.

​[1] The word “free” here is intentionally overloaded to include both “free lunch” as well as “free speech” or just “freedom”.  The forebears of the open source movement were very committed to the idea that free software is a requisite of human freedom.
[3] GNU was a recursive acronym, or an acronym that contained itself in its definition.  It stood for GNU is Not Unix.  Many of the early open source initiatives boasted similarly reflexive monikers: PHP (PHP: Hypertext Preprocessor), LAME (Lame Ain’t an MPE Encoder), and my personal favorite: XINHA (XINHA Is Not Html Area).
[5] Typically, these licenses require only that the original copyright and license notice be provided in the final product.
[6] In particular, the source code-distribution requirement of the GPL is generally not satisfied by a web application simply by virtue of the ability to view the source in the browser.  Most web applications call back-end functions on a web server, and this source must be provided as well (this requirement generally excludes GPL-protected products from a commercial software application).
[9] One recent exchange on a forum for a particular open source product: (Me): “does X do Y?”.  (Contributor): “No, but we’re always looking for contributors.”