![[#Beginning of Shooting Data Section] Nikon COOLPIX8700 Focal Length: 71.2mm White Balance: Auto Digital Zoom Ratio: 1.00 2006/01/01 10:59:56 Exposure Mode: Aperture Priority AF Mode: AF-S Saturation comp: 0 JPEG (8-bit) Fine Metering Mode: Multi-Pattern Tone Comp.: Auto Sharpening: Auto Image Size: 3264 x 2448 1/96.1 sec - F/4.2 Flash Sync Mode: Not Attached Noise Reduction: Off Color Exposure Comp.: 0 EV Converter Lens: None Sensitivity: ISO 100 [#End of Shooting Data Section]](https://techcrunch.com/wp-content/uploads/2022/03/GettyImages-85823299.jpg?w=1024)
Shaun O’Meara
More posts from Shaun O’Meara
The use of open source software (OSS) has exploded, and many companies are using it as the cornerstone of their infrastructure. When buying commercial vendor-supported software, you can expect the vendor to be in charge of the products’ upgrades, maintenance, integration and support.
By going the OSS route, this is no longer the case. Instead, you will interact with components built by different entities, individuals, or communities with different standards and goals. For example, the recent Log4j security issue led multibillion-dollar companies to request support from the project maintainers as they had a contract with them.
Companies need to put many elements in place to use OSS in production smoothly. Here’s how to get started.
Auditing
Before committing to using an OSS project, you first need to complete a full audit: How many contributors does the project count? Are they individuals or organizations? Most OSS maintainers are volunteers, and their level of involvement is never guaranteed.
You also need to look at the project’s velocity. For example, how many open feature requests or bug tickets are there? How quickly does the community answer and get them pushed? The goal is to ensure that the project is being maintained and evolving.
Finally, you need to audit the actual code. Is it well-documented? Can it handle the use cases and scale that you need? Picking the wrong project could become a costly mistake in the long run. Countless growing startups that picked what looked like shiny OSS projects were later compelled to spend tremendous effort decommissioning and replacing projects that could not keep up.
Staying up to date
Your team needs to stay up to date on the OSS projects that are used, which also applies to dependencies that come with it. A classic pitfall is a minor update going wrong, breaking your production. A recent good example is the startup SerpApi accidentally charging more than 400 customers after running what was intended to be a routine library update. Your team also needs to understand the project’s long-term direction: are they aligned, or are you at risk of feature deprecation?
Open source software can take a toll on the project maintainers. They may not have envisioned keeping up with a production-grade project, taking too much time and energy. Burnout is super-common among maintainers. Understanding who is contributing, if they are paid for it, their motivation for sticking around, and if they are thinking of leaving is tricky yet crucial information. A fragile community of maintainers is a red flag.
Prepare your team to interact with the code source
There are times when you may need to patch an OSS project. Whether it’s facing a bug or reaching the limit of what the project can handle scale-wise, there might not be room to wait for a fix to be pushed by the community. In that case, your engineers will need to dig into the code and find a way to fix it. While it’s an opportunity to contribute back to the project, keep in mind that getting to know a codebase, finding out what the issue is and coming up with a fix isn’t an easy task.
This is also true when an OSS project has a security issue – and it is not a matter of if, but when that happens. Your team needs to be able to have a quick and clear understanding of how the project is breached and the impact on the rest of the infrastructure and customer data.
Accept that doing it all on your own may be impossible
If assembling the team and skills necessary to carry out these tasks is not possible, an alternative way to run OSS in production is to partner with a vendor. They will be able to handle everything mentioned above with extra advantages such as offering packaged solutions that will ensure interoperability between the different OSS components.
You need to keep in mind a few elements if you decide to go the OSS vendor route. First, your team needs to keep an inventory of all the OSS they are using and have a clear understanding of what is supported by the vendors and what is not. Some vendors will only support a limited list of software, while some will go the extra mile to assist you no matter what you are using. Second, make sure to understand the level of support they provide for each: Are they only handling integration, patching?
Vendor companies will also participate and invest in the open source ecosystem by driving projects, co-governing and pushing code. You are directly contributing to the open source space by working with vendors, ensuring that the OSS tools you are using aren’t going anywhere.
Open source software comes with a lot of advantages, such as speed of innovation, cost and interoperability, but it also comes with a few caveats that can be easily addressed. Be sure not to ignore them.
Comment