Open source at Opencast

08 June 2022

This spring, Opencast formed a new open source team, with the aim of building and improving open source software ecosystems. Project team lead David Gregory explains.

Opencast has recently formed a new open source team. Our aim is to contribute to the long-term maintenance and improvement of the open source software ecosystems that we have used when delivering projects for our clients.
Photograph of four men with David Gregory, open source lead, pictured right
David Gregory (pictured right): "We will concentrate our efforts on helping existing open source projects with maintenance and new features, rather than publishing our own software"

What is open source?

Open source software is software where the source code is freely available for anyone to inspect, modify or enhance.

It’s used pervasively within commercial software, as there is a huge variety of open source software available that software developers can use to solve many common problems.

Today, open source projects typically use permissive licences that require little from users other than that they accept a warranty disclaimer and distribute the licence along with their product.

These permissive licences have contributed to an explosive increase in the variety of open source software, the number of contributors and the overall usage of open source software and tools in commercial software.

Why should companies contribute to open source?

Open source software is in a curious state. It is flourishing, but at the same time, the negative aspects of its contribution model are becoming apparent.

It’s rare that commercial companies contribute anything back to the open source projects that they use throughout their software, and due to the permissive licences used by open source software projects, there is nothing compelling them to do so.

Large commercial companies do contribute to open source, but it’s typically in the form of open sourcing selected pieces of their own software.

That is a wonderful thing, but it’s rare that these companies engage with the open source community in the way that an independent project would. Due to the dynamics of contributing to a project that is used within a commercial company, it’s rare for those open source projects to attract major contributors outside their originating company, and it’s rare for those projects to treat outside contributors as equal to inside contributors.

It simply doesn’t make a lot of sense to accept changes and features that don’t serve the needs of the originating company, because every new feature incurs maintenance costs, and every breaking change incurs migration costs for internal code.

It’s also rare for commercial companies to evaluate the state of the open source ecosystem before developing and releasing a new open source project. Since they prefer to exercise total control over their projects, they often release new libraries that solve a problem that is already well served in the ecosystem, rather than contributing features to existing projects in order to suit their needs.

Symptoms seen many times

We have seen the symptoms of these combined problems many times since it became common for open source software to be used by commercial companies.

In 2014 we saw the public disclosure of the Heartbleed vulnerability, which affected all software which used versions of the OpenSSL library released between December 2011 and April 2014.

OpenSSL is used in the Apache and nginx web servers, which at that time hosted around two thirds of active websites on the internet.

OpenSSL is used in those web servers to implement encryption of the traffic between websites and their users. This meant that private information like passwords, credit card numbers and other critical information could be stolen by attackers.

At the time of the disclosure, OpenSSL’s foundation typically received a paltry $2,000 a year in donations, mostly from individuals, was supported by 10 volunteer developers, and had only one full-time developer without outside employment. The foundation was resorting to work-for-hire contracts to sustain the project, which necessarily meant focusing on new features rather than improving and auditing existing code.

Vulnerability to attack

More recently, we have seen the disclosure of the log4shell vulnerability in the log4j2 library used throughout the Java ecosystem for application logging. The vulnerability allowed attackers to trigger execution of arbitrary code downloaded from the internet.

This would allow attackers to trigger their own programs to run on vulnerable systems to harvest credentials and data, among many other nefarious activities.

At the time of the disclosure, log4j2 had no full-time paid contributors. It was revealed that Ralph Goers, the contributor who wrote the patch for the log4shell vulnerability worked on the project in his spare time, and had only three users sponsoring his work on GitHub, all of who were private individuals.

All software can be expected to have bugs and security vulnerabilities. These vulnerabilities are not an indictment of those pieces of software or their contributors; they are a symptom of the lack of funding, contributors and security auditing that is offered to those projects as part of their usage by commercial companies.

It has become apparent that commercial companies must give time and contributions to the open source software that they have derived so much value from, so that the experts in that software can concentrate their efforts on the most difficult problems involved in supporting and developing their software, rather than the routine efforts of day-to-day maintenance.

A laptop and a green notebook
"We hope to cultivate a culture that encourages contributing to open source as part of day-to-day work"

How Opencast will contribute to open source

We intend to concentrate our efforts on helping existing open source projects with maintenance and new features, rather than publishing our own software.

So how has Opencast contributed so far?

I am the only full-time team member at present but a handful of other consultants have joined the team while preparing for other projects.

You can see a selection of our contributions below to get an idea of the things we have been working on:

What next?

Over time we hope to expand our contributions to other ecosystems as team members who are more familiar with different languages and frameworks are rotated onto the team.

We’re now planning a programme of internal events to enable our consultants to participate in open source development. We hope to cultivate a culture that encourages contributing to open source as part of day-to-day work.