Open source software (OSS) has long suffered from a "tragedy of the commons" problem. Most organizations, large and small, make use of open source software every day to build modern products, but many OSS projects are struggling for the time, resources and attention they need. This is a resource allocation problem and Google, as part of Open Source Security Foundation (OpenSSF), can help solve it together. We need ways to connect critical open source projects we all rely on, with organizations that can provide them with adequate support.
This problem is also similar to what economists call a "free rider" problem where the common resource is a man-made creation, as distinct from natural resources. To many corporations, open source software is a free resource, but unlike the natural resources in the
"tragedy of the commons", the resource is not consumed, and has the potential to grow indefinitely.
The problem with aging and potentially unmaintained open source building blocks has similarities with the problems of an aging transportation infrastructure, but differs in that every new bridge comes with a big price, while software costs little more whether used once or a billion times.
The best starting point for creating a more sustainable
open source software may be scientific research. At one time, science was largely a leisure activity of privilege. Now we have grants and fellowships to support researchers based on merit and societies needs and goals. Existing grant programs sometimes support development of new software in a closed timeframe, but do not provide ongoing support for maintenance. New programs could be designed to encourage proposals that identify critical open source components and provide a plan to remedy deficiencies and provide ongoing user training, maintenance, and support. One useful model is the HDF Group, which provides these services for the HDF5 library supported through grants and contracts with user organizations.
I once relied on an R library package that became unavailable after a few years. I tried to track down the author and was told: "He finished his PhD. Last I heard he was driving a taxi." I also encountered several R packages that could read and write HDF4 or NetCDF files, but were only developed to the point where they worked for the files the various authors were using. This resulted in several packages with overlapping capabilities and different capability gaps. Filling in those gaps would be hard work and would not have contributed to the requirements of the authors, but would have made the packages useful to a wider audience,
I have also encountered a number of examples where widely used software relied on library routines that were not well designed and could be replaced with much better routines from well-tested and maintained libraries. This highlights the need for testing, documentation that goes beyond the API and includes testing and performance comparisons of other libraries with overlapping coverage.