WDIM - Open Source Software

Introduction

Every company today, as well as every person with a connected device, uses some sort of software. Sometimes that software is a direct use software (note taking app to take notes), while other software is support software (Testing software to test software that is being developed). Regardless of the reason for the software, the group that is using the software has a very important decision to make: how will they get the software? Sometimes the users who need the software will try to build it themselves, other times the users will look for free software (why pay for something when you can get it for free, am I right?), and the last scenario (and often the last scenario) is purchasing the software. In all of these scenarios there is some sort of cost, but only in the last one is there an immediate recognized cost. Never fear! Open-Source Software is here! Or is it?

History

In the early 1970's most developers were openly sharing software they developed for the purpose of improving the field of technology. However, in the late '70's and early '80's, software began to be sold as solutions. Some still chose to freely distribute the software they were working on (Early Linux operating system GNU was one such software). Eventually, in '97 and '98, Netscape would become one of the major companies that would release their internet suite as "free software" (Mozilla Firefox used the Netscape source code once it became free). Those who started the free-software trend had formed a foundation called the Free Software Foundation (FSF), but were linked to unappealing social activism practices and eventually rebranded as the Open Source Initiative (OSI) in 1998. Ironically, one of the early opponents to the OSI was Microsoft, claiming that "open-source" technology would destroy the software and intellectual property business [paraphrased] (this is ironic considering how much OSS Microsoft is currently putting out). What is interesting in all of this is the fact that the FSF/OSI never intended to say that true Open Source Software should be "zero cost", but rather that the software had a "freedom to distribute" license model. This is an important distinction to understand, especially since most organizations that are looking for Open Source solutions are not doing so because they agree with the "freedom to distribute" license model, but rather because they don't want to pay for a solution (even sacrificing functionality, form, or feature in the interest of their bottom-line).

Open-Source as a Hero

When working in any organization, the desire to do your job better, faster, and/or cheaper can often lead to promotions or pay raises. In most cases, these accomplishments come from the adoption and integration of technological solutions which can automate different processes or tasks (Source code repositories, data entry, point-of-sale systems, etc.). But, getting budget approved for a robust solution which can solve your current and future problems is difficult at best. This is the main reason why some will attempt to build the solution, while others will look to free-software (aka, Open Source Software (OSS)) to fill the gap. After all, if a solution is free and can solve a real problem, why not go for it? This is where a quick google search for "OSS software for 'xyz'" will result in some github links to source code for open-source projects that a person or group of people have put together, blogs on how other companies are solving the issue with OSS, or even companies that provide services on top of OSS to "get you up and running in no time". Now that the research is done on the OSS solution, all of the problems are solved, right? Not exactly.

Open-Source as a Black-Hole

There are definitely significant OSPs (Open Source Projects) which not only solve some major pain, but they are also widely adopted in major enterprises (Jenkins is a great example of this). Yet Jenkins requires someone to build it, right? What about maintenance, integration, on-boarding, cost-of-ownership, enablement, etc.? There is a common saying: "There's no such thing as a free lunch". In the world of Open Source Software, there is no such thing as a free solution. In most cases, downloading the solution is the easiest part of the integration and installation process. After that is finished the user is then plunged into the black-hole of knowledge acquisition and configuration writing. Official documentation is the event-horizon in this case, diving deep into the knowledge base of how to get your other solutions to integrate with the OSS, what permissions and connections are needed, how to leverage APIs and scripts, any proprietary configuration language required for customization, among a host of other things. The next level is the unofficial documentation, leveraging the bug-ticket forum, community forum, stack overflow, etc. to figure out any strange nuances that you will encounter. Inevitably there are one or two solutions that the OSS cannot integrate with natively which will then require you to either invest your time in heavy scripting and customization or to accept the limitation and figure out how to switch between the two solutions. But, not surprisingly, many do not make it this far in their OSS adventure and will attempt to find a "Service Partner" who capitalizes on the difficulty of integration and implementation of the OSS solution and sells either services or plugins or both!

Why Does It Matter?

Every organization or group looking for a solution should definitely do their due diligence in finding the best solution for their situation (not just their current problem; important distinction to be understood). Make sure that the following concepts are considered to calculate the true cost of a solution:

• Licensing Costs (does the solution require some type of purchase?)
• Enablement Costs (professional services require time and money)
• On-Boarding Costs (training = time = money)
• Cost of Ownership (how much will it cost to host and run the solution?)
• Maintenance and Up-keep (is there ongoing maintenance for updating the solution or updating the custom configurations scripts/files?)
• Security (how is the solution secured and does it allow you to keep your secrets secure?)
• Integrations (how many of the current solutions in the organization will and will not integrate with the desired solution? Are the lack of features or integrations acceptable?)
• Community (is there an active community that both uses and improves the solution?)
• Knowledge Base and Documentation (is the documentation easy to understand and extensive?)
• Add-Ons (are professional services required or offered and is that an acceptable spend? Are there extensions or plugins that can be added to the solution for greater functionality and are they worth the time to implement?)
• Innovation (how often is the solution being added to or improved? How often are bug releases or hot fixes delivered to production?)

Hidden costs are the worst kind, almost as if you are being taxed for using a solution. Make sure that the total cost (time, effort, AND money) is accurately understood and counted before any solution is pursued. Just because there is no immediate invoice doesn't mean the solution is free.