Skip to main content

The stumbling blocks of open source in companies

Without open source code, the world as we know it would come to a screeching halt. Even corporate software is full of it. And rightly so: no-one benefits when you invest time reinventing the wheel. Yet open source code is not without risks.

1. Amateurs or professionals?

The first big question mark is the quality of the code. Generally speaking, open source has a good reputation. Professional developers from all over the world work on major projects. Updates with sloppy code are cleaned up and best practices are followed. But not every project has as many followers as the Linux kernel. With small pieces of open source code certainly, you have to pay attention. A useful piece of code may have been built by ten professionals, but equally by a first-year student with a lot of ambition but not much talent, working alone.

A few rules of thumb can help. For example, check the quality of the accompanying documentation and the number of commits. Online tools can help, too, or you can take a random sample yourself. The first step is to be aware that a handy project is not necessarily a good quality project.

2. Support

And then you need to keep the support in mind. Large, popular projects find volunteers to keep them going, but what about the smaller or less targeted pieces of code? The pet project of a Java guru somewhere in the mountains of Nebraska may prove useful for twenty years, until the founder takes a well-earned retirement and says farewell to the world of 0s and 1s. Suddenly the project stagnates, although the code is an essential part of the business application that you developed.

That’s why it’s a good idea to gauge how much enthusiasm there is for a particular component. Do you see a six-monthly commit from the same expert? Or are colleagues all over the world working on it weekly or daily? If a project that’s as good as dead is really handy, you can, of course, consider sponsorship. The open source community gives, as long as people are prepared to give back.

3. What are you allowed to do with it?

Just because you stay away from big companies does not mean that licences are suddenly a thing of the past. Open source is subject to licences, too. For personal projects you don’t have to be too concerned about this, but when you integrate code into a business application, it’s best to think carefully about it.

Open source licences come in a wide variety of forms. Some licences allow everything. In that case, you can adapt the code of a component without a care and use it in the application you are building, regardless of whether it is for internal or external use.

It’s different with so-called copyleft licences. Code that is subject to a licence like this can be used in your own software product whenever you wish, but you are expected to share the adaptations with the open source community when you share the finished software with the world. If you are building a commercial business application with an open source component, this condition can be problematic.

And what about all the code without a designated licence? This, too, is subject to copyright legislation. The use of such code in commercial products involves risks. So take good care before integrating a piece of code into a business application.

4. Secure but not infallible

Finally, it’s best to think about the security repercussions when you integrate open source code into an application. Because everyone can take a look at open source code, it is usually much more secure than alternatives developed within companies. Five hundred pairs of eyes see far more than five pairs and these days, no-one believes in security through obscurity any longer.

Even hundreds of people can drop the ball from time to time. Just look at the popular open source logging tool Log4j. It is integrated into tens of thousands of applications across the world, from SMEs’ own business applications to software of giants like VMware. Log4j proved to have just one critical fault, and that is having major consequences. Everyone who has integrated the open source component into an application now has to provide an update for the application.

That’s fine, as long as you have a clear idea of which open source components you used in your own projects and you keep an eye out for vulnerabilities. So keep a good record of which components you integrated where and monitor their status regularly.

5. Management

Ultimately, there is one golden rule: know what you use and where. If you keep a close eye on which open source components are included in which business applications, and on the development of the open source code itself, you won’t have problems any time soon. As long as you don’t forget that free of charge is not the same as licence-free.