Skip to the content.

Open Source

A few keywords: * maintenance * Succession planning, handover * Security issues

Support service for Open Source projects

The problem, as also described by xkcd is about dependency

How can you and your company reduce the risks related to Open Source projects. Especially Open Source projects going unmaintained?

Your company depends on many open source libraries, for example the Perl modules or Python packages you use in your applications. Replacing those libraries would be costly to your teams and thus it is valuable to make sure these packages are maintained. Bugs are fixed, new features are added, Pull-Request and Issues are handled, etc. This can be achieved by asking your employees to spend time on these projects, but it would likely be very costly. Besides, your employees are already busy.

My offer is to take a list of modules your applications depend on and provide continuous maintenance for them. This will

Learning about the specific needs of the team will help me steer the projects in the directions that will be beneficial to the team, eventually saving time for them.

We will agree on a list of Perl or Python libraries that are covered in our contract. Your employees will be able to send us technical questions about any of the libraries we include in the contract. We will monitor the development of each one of these projects to ensure issues are handled on a timely basis. That the project has an adequate test suite,

Create a report on each one of the open source projects - bus factor, activity, level of risks

Case studies

As it turned out they contacted me some 3 years after they implemented that change. They wanted to upgrade to the most recent version of the module, but could not do it easily as they had local changes. I looked at the problem they fixed locally and found a couple of things. * The fix the company implemented locally had an obvious security issue opening the code to SQL injecttion attackes. It risked the company, their clients, and would have never been accepted to the open source project. * There was an issue opened about that problem even before they “fixed” it internally. * There was even a patch attached to the issue (this was before GitHub and pull-requests) that dated before the “local fix”.

This whole thing could have been avoided if they understood how to really work with open source projects or if they had a contract with someone to make sure the packages is maintained properly.

One of the dependencies (in our case C) deprecated a feature that was used by B and we started to get deprecation warnings. Unfortunately package B has not seen a single commit in more than a year. Even though there are new issues and new pull-requests waiting.

At one point that deprecated featuer will be removed from C. At that point the client will be stuck with an old version of C. Slowly other dependencies might start to require a new version of C. At that point more of the clients dependencies will be stuck in the past. No security fixes and no criticial fixes will be applied to the old versions of these packages.

Maintenance issues

How do companies handle the risk?