Open Source Velocity (OSV):ㅤDirections & Trends in the Future of Open Source.ㅤMapping a Path to a Sustainable Open Source Ecosystem.

This has never happened before.¹²

Summative.

     After reviewing the data, one may wonder why the sum of closed and open issues does not total to the number of issues reported in the “Issues” column. That is because open issues persist from year to year until they are closed. It is a summative column.
ㅤ

Unprecedented.

     What is being reported in the “Open” column is the number of issues from each of the years examined that still remain open. What is most noteworthy is that the number has never exceeded the number of issues closed in a year until after 2020.
ㅤ
For instance, one may navigate to GitHub and search for open issues that have a created date in a particular year. What one sees here are those issues created in the year 2010 that are still open today.
ㅤ

Dynamic.

     The number will almost certainly not match the one reported in the table above because issues are constantly being resolved. The rate at which issues are resolved is a key indicator of the sustainability and velocity of open source.

What is Open Source Velocity?

     Velocity is the directional speed of an object in motion as an indication of its rate of change in position as observed from a particular frame of reference and as measured by a particular standard of time.

     Open Source Velocity (OSV) is the directional speed of the open source ecosystem’s movement notated as the rate at which it may be said to be becoming either more sustainable or less sustainable.

Measuring OSV.

     The difference in the steepness of the line graphs for open and closed issues indicates OSV.

     With the chart of "Closed and Open," issues illustrated here, one may observe that since 2020, the rate of accumulated open issues has increased over three times as steeply (with a 75% YoY increase) as the rate at which issues are closed (only a 20% YoY increase).

     When one subtracts the rate of open issues from the rate of closed issues, one discerns that unresolved issues are accumulating 55% faster than the speed at which issues are being closed. This is a negative, less desirable, less sustainable trend for the open source ecosystem.

This report does not yet factor in:

• + How much time it takes until an issue is resolved for the first time.

• + The inquiry also does not make distinction between projects of different license types.

• + A future examination should also factor in how many issues are re-opened as well as the disposition of closed issues (e.g. "won't do, duplicate, etc.").

• + Finally, at a later date, an examination of the dependency graph, the way in which various projects' functionalities rest upon one another, should also be conducted.

59% of 204 surveyed maintainers either quit or considered quitting their maintainer role.

Those surveyed were able to select all the reasons that they felt applied. Remarks on the results of the reasons maintainers quit follow.

      What can be made of the unprecedented number of unresolved issues and the fact that maintainers are quitting? What do these aspects of open source mean for its future? It comes down to the number of persons handling the issues as well as how that work is being achieved.

     That answer is indicated in Clyde Seepersad’s April 2022 article titled “You Can’t Hire Your Way Out of the Cloud Skills Shortage.” Although Mr. Seepersad speaks of the shortfall of cloud computing talent needed, the same holds true for open source talent more broadly. Clyde’s remarks were reported in the software media publication “The New Stack”:

Organizations need to realize that no matter how high of wages they offer, how many acqui-hire deals they engage in, or how heavily they recruit, they are not going to be able to fill all their needs for cloud talent. The only way to face this challenge successfully is to take steps to grow the talent pool itself. There are several actions organizations can take to make progress in this area. For most organizations, it will not be enough to implement one of these actions, rather multiple pieces will be required to get your cloud teams fully staffed. Companies need to adopt an “all of the above” approach to talent acquisition.

         — Clyde Seepersad
             Senior Vice President & General Manager
             Training & Certification, The Linux Foundation

     What is clear from Seepersad’s statement is that ecosystems that were once held together via legacy staffing approaches can no longer do so. This is because of the enduring and massive skills gap in the tech sector. For instance, before COVID-19, the American trade organization, The Computing Technology Industry Association (CompTIA), noted a gap of 918,000 tech workers needed in a single quarter.¹⁴ And, according to "The Linux Foundation’s 2021 Open Source Jobs Report: 9th Annual Report on Critical Skills, Hiring Trends and Education" the “talent gap that existed before the pandemic has worsened due to an acceleration of cloud-native adoption as remote work has gone mainstream. With talent shortages around the globe, training existing staff has become even more important to meet the needs of migrations to the cloud and leverage open source technologies tied to those migrations."

     In summary, yesteryear talent approaches to meet the demands of the present moment are insufficient.

     When COVID-19 upended markets, forty thousand MLH community members lost out on internships or their first job offers. Hiring freezes took hold. Burnout ravaged management structures. And it was out of this mayhem that the MLH Fellowship was born. The impact that the Fellowship promises to have on OSV is a positive one that will be detailed in the following section.

MLH’s “Season Census” surveyed 14,000 respondents in the Spring of 2022. These charts refer to programmers residing in the US, UK, Canada, and Ireland.

... it is evident that there are some self-limiting beliefs constraining these early-career developers from participating in Open Source.

• 1.  More than half of the respondents who do not contribute to open source, over twelve hundred, are coders with more than three years of experience. And yet, they do not believe they have the skills necessary to contribute to open source. Or they say they do not know how to get started.
• 2.  More than five hundred programmers not contributing to open source indicate they possess no less than five years of experience.
• 3.  Around fifty-five have practiced for about a decade.

Mr. Eberhardt systematically examined the development toolchain, the set of software libraries acting as dependencies, for the use of Express JS. In his analysis, Colin finds eighty-eight maintainers committing and deploying functionality that is downloaded by public, private, and social sector organizations as well as individuals over forty million times every week.¹⁶

Given the outsized importance for hundreds of millions of projects that even a single maintainer could have, the community benefits from thoughtfully integrating those with even only a little experience to do suitable tasks. Coders may still find ways to contribute to necessary open source assignments given the right guard rails.

In a traditional internship, an assignment generates a deliverable that belongs to the company that is hosting the intern. To help with OSV, MLH Fellows are, instead, making public contributions to open source software that nearly all companies depend on. By contributing publicly to projects that undergird the efforts of numerous endeavors rather than only to one organization, MLH Fellows model a path toward a sustainable vision of an open source ecosystem.

The momentum behind the MLH Fellowship helps OSV.