While having conversations with a couple friends the last few weeks, I came to the conclusion that there might be value in writing down some of the ideas I have floating around in the big tin-can on my shoulders, as it relates to opensource software (oss).
Or, then again maybe not.
Regardless, I took a few minutes to jot down some thoughts. This list is by no means exhaustive, it’s just a quick brain dump around what comes to mind when I think about using oss in the enterprise.
Talent implications:
There are some definite and perhaps obvious implications to attracting talent when it comes to participating in the oss community. First and foremost, it is an easy way for an organization to market itself, its culture, its people and its technology capabilities. Secondarily, in my mind, developers that engage with the oss community show an increased dedication and passion for ongoing learning and development outside of the 9×5. So participatory individuals definitely represent a type of individual I want to have in my organization.
Technology practices:
OSS can be fickle, as it involves many people with diverse backgrounds and perspectives agreeing to agree. 😊
When using oss, I would suggest setting up a company repository where oss and dependencies are curated and maintained as approved for corporate use. In addition, I would also recommend blocking teams from using external repositories, in order to manage and mitigate various risks based on company appetite. JFrog Artifactory is one such example of a solution that can be used for a corporate repository.
The link below gives a brief example of what can happen if you aren’t careful in how you manage the repository in the oss world. 😳
In addition, in order to maintain bench strength, autonomy, ensure continuity, and enforce corporate quality gates, it is also important to not become reliant on compiled binaries; as such, I would ensure the company has the toolchains and configurations to compile source code into binaries in a CI/CD type of model.
Security of open source:
On the upside, oss allows for easier identification and crowdsourced remediation of vulnerabilities; however, on the flip-side, it is easier for hackers to identify vulnerabilities, fingerprint companies using the oss, and subsequently exploit vulnerabilities, without disclosing them.
Thus, it is important to have a solid program in place for monitoring for emergent vulnerabilities and patching in a timely manner, especially for externally facing solutions. This also drives back to the discussion of having a centralized repository for curating approved oss.
Licensing models:
I’m not a legal expert by any means but know enough to state that careful considering needs to be made as it relates to the usage and mixing of different license models in the oss and proprietary world.
As an example, some license models cannot be combined with others and some licenses like “copyleft” licenses are viral (to a greater or lesser degree) and may require disclosure of source even for derivative or combined works.
In addition, there are nuances and interpretations related to words like “propagate” or “distribute” when modifying oss. As an example, using it on your internal corporate network may have different implications compared to embedding it into a website and having people remotely access it, which may also be viewed differently than using it in the mobile app and putting it in an app store.
Cost factors:
OSS has many cost factors, but I saved cost for last because it is tired to all the previous discussions. While the initial investment is often lower for an individual package, taking on maintenance and support for more complex oss packages will likely increase the TCO and have a negative impact on opportunity cost over time, as you will have teams that will need to continue to maintain and provide upkeep for what is likely to be a commodity for the organization – rather than focusing that same time slice on things that are of a competitive advantage.
Summary
A quick wrap up. I am a huge proponent of both the concepts and implementations of oss, however, I often see companies going down the route of oss because it is perceived to be “cheaper”. While, in some cases, that may be true, especially for smaller companies with very limited IT budget and a high tolerance for risk.
My advice is to think through the risk and exposure around the use of OSS for the company, and then compare what it would take for investments to make oss elevate to the same first class citizen as internally developed software. That’ll give you a head start on understanding the TCO and opportunity costs of using oss in the overall aggregate of your technology economy.
Finally – while I admit, I really haven’t read much of it, this looks like a great resource. https://opensource.org/faq
My hope is that you will find ways to manage the corporate risk, and still commit to engaging with, and supporting the OSS community!
As always, I am happy to learn from others, so if you have a perspective you’d like to share on oss – feel free to reach out to me and engage.