DEV Community: Serkan Holat

The US Government, Open Source Software and Analyzing 786 Pages of Responses - Highlights

Serkan Holat — Fri, 15 Dec 2023 11:55:40 +0000

A semi-professional content analysis on the submitted responses to the US Government's Request for Information on Open Source Software

Part II: Highlights

Welcome to the second part of the series, covering the sections that stood out while reviewing the responses to the US Government's Request for Information (RFI) on Open Source Software.

You will find a compilation of highlights from 25 organizations, including tech companies, foundations, universities, and security firms. Mainly in a single-paragraph format and alphabetically ordered, they are collected under seven topics, each with a link to the original response and without additional commentary.

As a reminder, my priority centered on how the organizations define open source software, its challenges, and the proposed solutions, particularly from a funding perspective. Therefore, you will see fewer items related to technical solutions, even though the RFI's primary focus is on software security.

Enjoy reading the collection, which I hope should provide a distinct insight into the overall state of the ecosystem. As always, please feel free to share your thoughts and questions!

Topics

Current State
Facts and Figures
Most Important Area
Public Funding
Ideas and Insights
Let's Be Frank
Rules and Regulations

Current State

Anchore, Inc

Modern day funding of core open source projects is not likely to generate revenue, because the current development model is not sustainable for many small open source projects. As a result, the current open source model does not incentivize or reward secure development practices.

Chainguard

In sum, open source software security is a public policy problem in the same way that “health” or “housing” or “foreign affairs” is a public policy problem. It’s just newer. And that newness is exciting, but that same newness should also be a reason for some caution and modesty.

Eclipse Foundation

One of the greatest challenges to sustaining open source software lies in its economic model. Access to the benefits of software which has been developed and licensed as open source is freely available to all actors in the ecosystem. Many companies deriving the benefits of OSS for a range of well-understood reasons contribute back to the projects which serve as the basis of their commercialized offerings, while many more do not. This later behavior is referred to as “free riding” and is not one of the industry’s better practices.

Microsoft Corporation

To deal with [the lack of investment and participation in open-source software] challenges effectively, governments must adopt a long-term view that considers the security, sustainability, and resilience of these vital systems. Instead of prioritizing short-term interventions, governments should invest in holistic solutions and strategic partnerships that lower systemic risk, improve efficiency, and increase competitiveness.

Open Source Initiative (OSI)

However, many companies that rely on OSS do not contribute back financially to the OSS projects and communities upon which their service offerings rely. The very licenses that govern open source require freedom of use, which means that the commercial entities that use OSS are free to do so without contributing to the security and health of the software. This is sometimes referred to as the “free-rider” or “tragedy of the commons” problem. This freedom to use and reuse has resulted in a boon to innovation, but not in economic equity and sustainability. Inconsistent support for open source projects by the commercial entities that use them has been a difficult problem to solve.

Open@RIT - Rochester Institute of Technology

In an era where digital advancements are critical for addressing global challenges, including climate change, public health crises, and technological innovations, there is a growing recognition that the siloed nature of digital infrastructure development is unsustainable. To harness the full potential of digital knowledge, it is imperative to foster an environment that promotes openness, collaboration, and the removal of barriers to access.

OpenSSF

As a public good, there is a market failure when it comes to dedicating resources to open-source communities. There are few incentives for many organizations to participate, and yet those organizations all benefit when another organization does commit resources and personnel to the cause – a variation of the "tragedy of the commons."

Rust Foundation

A related issue that represents a real security and stability risk in Open-Source is the reliance of Open-Source Software Foundations upon the goodwill of private sector companies to donate their resources in-kind to cover these infrastructure costs. As it currently stands, the world's basic infrastructure and hosting costs for Open-Source languages (not only Rust, but several of the top 10 most used languages in the world) are supported by only a handful of vendors. Any one of these vendors exiting the market or pivoting their strategy would deal a severe blow to the security and stability of the ecosystem, and would have the potential to effectively bankrupt the Foundation affected.

Tidelift, Inc.

The bottom line for the impact of volunteerism on government and industry is that deep, fundamental security work requires constant, consistent work and uncompensated volunteers don’t typically get work done on a constant, consistent basis.

Facts and Figures

Apache Software Foundation

While that scenario of individual developers may seem like an outlier, it is not an insignificant portion of the ecosystem. The 2022 Census II of Free and Open Source Software found that 94% of projects had fewer than ten developers accounting for more than 90% of the lines of code added. In 49 of the top 50 non-npm projects reviewed, nearly a quarter of them had only one developer responsible for more than 80% of the lines of code added.

Open Source Initiative (OSI)

The FreeBSD Foundation has also identified three security roles that it needs to fill in order to strengthen the project’s security posture to meet current and future needs. These three people will add $500,000 in currently unfunded annual salary expenses. Significantly securing critical OSS software will require a significant increase in investment.

Python Software Foundation

The first version of PyPI was opened for public use over twenty years ago in 2002, and it continues to be the main repository for open-source Python packages. PyPI has grown to host over 490,000 distinct projects, with over 5 million releases, which are downloaded collectively over a billion times per day. Maintainers upload roughly between 12,000-15,000 new releases per day to PyPI. PyPI website typically receives between 3.7 and 4 million unique visitors (humans) per month. PyPI receives approximately 3 billion web requests per day for projects hosted on its infrastructure (approx. 90 billion per month).

A large volume of projects on PyPI ... are maintained by volunteers, not by corporations. Many projects are even maintained by a sole maintainer, often without the resources or even the knowledge to update their package publishing processes to more secure methods. Out of 490,000 projects on PyPI, 91% of projects have a single account with the maintainer role.

Rust Foundation

The scaling and adoption of memory-safe languages such as Rust has related challenges in the associated scaling of the infrastructure that supports the language. The Rust Foundation is responsible for hosting Crates.io, the package repository for Rust, which alone costs upwards of $40k per month as of August 2023, and this cost rises monthly as the development and adoption of Rust increases. This is one of several infrastructure costs that the Rust Foundation is obligated to meet in order for individuals and companies to use the language to build.

Sonatype, Inc.

Over the last decade, Sonatype has seen first-hand an escalation of attacks that directly target developer and development infrastructure; Solarwinds is just one example of this type of attack. As part of our efforts to secure software repositories, Sonatype has also invested in human and AI/ML approaches to address these new attacks via malicious packages. Having identified over 250,000 malicious packages, the threat to OSS via public repositories and package managers is real.

Tidelift, Inc.

Similarly, somewhere around half of open source maintainers do that critical maintenance work alone. In our survey, about 44% of maintainers said they were solo maintainers, and other studies report similar numbers (eg, 57% in the [referenced] study of the most popular projects, and perhaps 93% in the [referenced] study of Python).

Most Important Area

Carnegie Mellon University - Software Engineering Institute

In summary, the Software Engineering Institute (SEI) considers the behavioral and economic incentives area to be the most important as the incentives will need to influence the behavior of the OSS ecosystem thus achieving the goals of the Open-Source Software Security Initiative's (OS3I) proposed initiatives. Without such incentives, the OSS ecosystem will likely continue its current path and trends likely without the changes the OS3I is attempting to achieve. Though this area is the most important for improvement, it may also be the most challenging. The OS3I and government must devise incentives that will work for the diverse and global open-source software ecosystem. That understanding is not as much a technical one as it is a socioeconomic one. Without that understanding, no amount of technical advancement will be effective. With that understanding, OS3I can engage with the open-source software ecosystem to understand the gaps that exists between OS3I's desired state and the interests of the other stakeholders within the ecosystem as to what foundational needs, technical as well as socioeconomic, are required to close that gap.

Tidelift, Inc.

[Our] response to the ONCD Request for Information will focus specifically on the RFI topic area of “incentives for securing the open source ecosystem.” We believe that this is, in many ways, the most important area called out in the RFI. Open source is not magic! While other areas called out in the RFI are important, if incentives and motivations of open source maintainers are not well-understood by policy-makers, those other improvements will not happen, or will happen only slowly. That puts the question of incentives and motivation on the critical path for almost all other improvements to the security of the open source ecosystem.

Public Funding

Amazon Web Services

Many, if not all, of the recommendations, actions, or potential regulations that may emerge as a result of this RFI will require significant work from maintainers and producers of OSS projects. In some cases the outputs of this process may lead to ongoing costs for things like additional infrastructure and recurring audits. Many OSS projects are run on an entirely voluntary basis by people who are not paid for their efforts, providing them with a significant challenge to fund this kind of additional work. Additionally, any risk of inequitable liability requirements will diminish their available funds to support OSS security best practices and requirements. Just as many other items discussed in this response require funding, finding a way to fund the work needed from small, independent projects is an important element of this overall effort that must be prioritized.

Organized funds to improve open source security are already having an impact. Linux Foundation’s Alpha-Omega Project, Germany’s Sovereign Tech Fund, and, while not its specific focus, the United States’ Open Technology Fund have all contributed to improving the open source supply chain. Innovative efforts like the Open Source Technology Improvement Fund (OSTIF) is finding a way to bridge the communications gap between security professionals and open source project maintainers. More is needed to secure the critical foundations of our shared digital infrastructure, and the USG is in a good position to help advance these existing efforts, and potentially establish new ones.

Atlantic Council - Cyber Statecraft Initiative

Several federal entities such as NASA and the NSF already provide forms of funding for OSS projects, communities, or research. OS3I can leverage its position as an interagency coordinator to collate lessons from these entities learned in their OSS funding experiences into a best-practices framework for government funding.

For timely responses to urgent needs in key OSS projects—for example, those heavily used in government or critical infrastructure—government should have a means of quickly allocating funding or other security resources such as developers, infrastructure, or security audits to those projects when required.

In addition to targeted and timely interventions, government should seek a vehicle for longer-term, sustainable investments in the health of the OSS ecosystem. Government is uniquely well-positioned to take a long-term view on the public goods created by OSS and invest in initiatives to shore up the health of the community to promote these public goods and to forestall costly crises down the line.

Eclipse Foundation

Explore the feasibility of creating the equivalent of the Sovereign Tech Fund in the US, with a focus on contributing to sustaining and improving security of the open source software which the US federal government depends upon which might otherwise go untended. Choose a federal agency to create an appropriate agreement to underwrite the effort and give the program a three year pilot period to demonstrate impact.

GitHub

The federal government should establish an open-source software infrastructure fund like the German Sovereign Tech Fund model. One implementation option would be to expand the Open Technology Fund’s recently established Free and Open Source Software Sustainability Fund with a simple mandate to support important open source digital infrastructure.

Google

Open source software is a critical element of US digital infrastructure that needs financial support through new and existing public funding sources. The federal government should partner with existing OSS foundations such as the Rust Foundation, Python Software Foundation, Eclipse Foundation, Linux Foundation, Open Source Security Foundation (OpenSSF), and many others with expertise in this space. The federal government can leverage their collective knowledge and relationships to most effectively direct funding and support to key projects.

The federal government should consider expanding the availability of public funding programs for open source technologies, similar to grant programs such as the OpenSSF’s Alpha-Omega Program, US AGM’s Open Tech Fund, Mozilla’s Open Source Support Awards, and the German government’s Sovereign Tech Fund. The National Science Foundation’s Pathways to Enable Open Source Ecosystems (POSE) program is a promising experiment in direct public funding of open source innovation, and we applaud its mission to foster wholly new open source foundations and ecosystems. POSE would be most effective if paired with a funding vehicle in the form of an “Open Source Tech Fund,” providing financial support for US and international organizations that maintain key open source projects. This support will help ensure the security and sustainability of critical, widely used and free public services like software repositories.

OpenSSF

Identify critical OSS projects/foundations and support them to improve their security, through funds or other contributions. One example is the Alpha-Omega project, a technical initiative of the OpenSSF. Alpha-Omega provides a path for industry to come together to catalyze critical OSS projects and foundations as they improve their OSS security in systemic and durable ways. It does this by funding security staffing, ecosystem-wide improvements, project audits, and security tooling. We would also like to see the OS3I supporting a government funding parallel to Alpha-Omega, similar to Germany's Sovereign Tech Fund or the differently focused Open Technology Fund.

Ideas and Insights

Atlantic Council - Cyber Statecraft Initiative

Government OSPO: The OS3I should serve as a prototype for and coordinator of US government open source program offices (OSPOs). First, OS3I should collate lessons learned from OSPOs in industry, academia, and US and foreign governments into guidance for US government agencies developing their own. It should also coordinate existing and future agency-level OSPOs or similarly tasked offices and serve as a functional single point of contact for OSS issues communicated to the US government in coordination with the ONCD, rerouting outreach to the correct offices and backstopping where none yet exists.

Tracking dependencies: The rapid pace of digital innovation and the informal relationships between OSS dependencies and their downstream beneficiaries has created a digital ecosystem prone to stacking risk on a relatively small number of critical OSS projects. It’s also created challenges for entities—including government—seeking visibility into those points of concentration. Tracking dependencies is key to managing risk, and OSS dependencies run deep and quiet—US government cannot secure what it does not know it relies upon, hampering its ability to preempt or respond to crisis.

Cybersecurity Coalition Comments

All software: While utilizing memory safe languages can contribute towards more resilient software, it cannot be viewed in isolation. Practicing safe cyber hygiene and abiding by industry best practices are also important factors contributing to the overall security of open source software security. It is important to remember that all software has the potential to contain vulnerabilities, and therefore we should avoid concentrating on specific technical issues and instead focus on the overarching security of all critical software.

Tech is evolving: We would also caution against mandating certain controls or specific memory safe languages. Technology is always evolving, and what may be considered best-in-class today could change tomorrow. Therefore, mandating specific controls in a regulation that could stand for decades is short sided. Instead, requiring ‘adherence to security best practices’ or referring to standards or frameworks that are more regularly updated is preferred.

Datalytica

Federally-funded bug bounty programs: The current and most popular bug bounty programs are “Hack the Pentagon” and “Hack Department of Homeland Security (DHS)”. One drawback to these efforts are that they are time-bound events, which some cybersecurity experts believe may not deliver consistent security improvements. A dramatically improved bug bounty program would persist over time and would involve increased public transparency (e.g., live streaming with Social Media presence, drawing broad viewership), industry collaboration, increasing the incentives, and expanding the scope of targets.

Eclipse Foundation

SBOM registry: Creating a centralized, accessible SBOM registry that not only stores these materials but also performs automated analysis could be a game-changer. The registry would offer to store an SBOM for any official release of any software product. This could include simple tasks such as automatic conversions (when possible) between CycloneDX and SPDX, automatic dependency checks, license compatibility evaluations, and even security vulnerability assessments. It could also compare SBOMs generated by different providers (for example different Linux distributions shipping the same software with slightly different options). Such a service would provide immediate, actionable insights for developers, making SBOM generation a value-added activity, because of the access of those additional functions. Results of the analysis should be publicly available.

Institute for Security and Technology (IST)

Centralized database of known vulnerabilities: We encourage the U.S. government to focus first on developing a centralized database of known vulnerabilities, along with tools and approaches to identify vulnerabilities at scale. It is critical to first understand the scale and scope of the open-source ecosystem and its associated security issues before identifying opportunities to increase its security.

OWASP Foundation, Inc.

On memory safety: Memory safety is not a panacea. Memory safety helps with a bug class not highly present in web application languages, frameworks, and APIs - buffer overflows. OWASP notes that memory-safe languages do not address the following bug classes, including insecure, insufficient, or missing:
• Architecture
• Authentication and Session Management
• Authorization
• Input validation and output encoding
• Cryptographic Flaws
• Error Handling
• Data Protection and Privacy
• Secure communications
• Malicious code checks
• Business Logic Flaws
• File and Resource Handling
• API Security
• Configuration

Open Source Initiative (OSI)

Updating procurement rules: Through a multi-agency effort, the federal government should update its procurement rules to prefer technology suppliers that demonstrate financial and/or engineering support for the OSS in the suppliers own solution stack. This preference should apply to both cloud and on-premises solutions provided to the US Government.

Python Software Foundation

Centrally curated toolset: Right now, projects need to adopt each standard or tool implementing the standard individually and must use customized workflows or configurations, which dissuades many projects from adopting. Toward these standards being adopted by critical open-source Python projects, we propose creating a centrally curated toolset for building Python packages with optimal security practices enabled by default. A central toolset would require a relatively small investment to leverage existing security technology to create widespread adoption in one of the largest open source ecosystems in the world.

Surveying the ecosystem: Because every migration of a project into memory safety requires time and resources, it is critical to prioritize projects that are most important to migrate and to avoid placing undue burden on projects which are less or not safety-critical. The nature of open source consumption doesn’t lend itself to knowing how and where a project is being used, so many project maintainers don’t know whether security must be prioritized for their own projects, increasing the complexity of this task. Effectively prioritizing candidate projects for migration would require surveying the ecosystem with usage information (number of downloads, dependency graph information, and input from consumers like the federal government) and whether their primary function would benefit from using a memory safe language (such as packages implementing cryptography or processing uncontrolled inputs).

Red Hat, Inc.

On package repos: Engagement with these key centers of distribution [‘warehouses’ (also known as package repositories)], which fill a vital function and are heavily depended on by the ecosystem, to improve their security posture could reap significant systemic benefits for software developers, vendors, service providers and users. Many of the packages and much of the community code found in warehouses are unsigned and have little information on their provenance. As a result, it is challenging to validate that the software received is authentic and intended for use by the maintainer, whether it is legitimate, or whether it is safe.

On memory safety: The fact is that there is a growing use of memory safe languages in development communities. This is a major step forward in good programming practices. However, it is of no value when hastily implemented by developers lacking the proper training and experience to develop quality software. An experienced and security-focused C++ developer is more likely to produce code of greater efficiency and execution security than an inexperienced Rust developer.

The Open Source Technology Improvement Fund

Identifying the under-maintained projects: Projects first need to be identified and categorized by their lifecycle status, language, and relationship to critical infrastructure. There are millions of projects across billions of installs, so we need to prioritize appropriately. A critical exercise that will take approximately $10 million and between one to two years to complete is the identifying of projects in our infrastructure that are under maintained. The administration can start with supporting the Software Bill of Materials and any initiatives that identify software that is no longer maintained.

Let's Be Frank

Chainguard

Un-asked question: ... the U.S. federal government should first define, assess and improve its own open source software security and, next, that of critical infrastructure, before seeking to contribute broadly to the safety and security of free and open source software writ large.

Why focus on the federal government’s own open source software supply chain? Because it’s mostly a black box and likely full of the known dangers and risks that companies and open source software developers have been coping with. Does any entity within the federal government have a machine-readable list of all the software that entity depends upon and the open source software components within it? If the answer is no, and all indications are that the answer is no, then assessing the open source software security of the government isn’t even an unsolved problem; it’s more like an un-asked question.

Sonatype, Inc.

No intention for change: Unfortunately, we have observed and heard directly from organizations that do not believe the government intends to change the status quo. Their belief is supported, in their opinion, by a lack of specific action by the federal government to hold software organizations directly responsible and accountable. Given this, they hold much of the current rhetoric and public discourse as nothing more than pageantry with no intention for change.

Sonatype does not hold this belief but recommends that the government should take clear, public steps in demonstrating the actions and capabilities of the federal government on these issues.

The Open Source Technology Improvement Fund

Very few good feelings: You need to build trust with the community which has been slowly chipped away over decades of government secrecy, spying, oversight, and perceived miserliness. In order to accomplish even the short-term projects suggested by this RFI, it will be necessary for the government agencies working on this to set aside their egos in the name of enacting change. Frankly, no one in the open source industry is going to willingly sign up for projects that are directly and singularly run by government agencies. There are very few good feelings towards government management or involvement in open source, especially in security. What you need to do is demonstrate that this government is transparent in its funding and support of security improvements for projects with no ulterior motives.

The biggest challenge: Possibly the biggest challenge in defining and acting upon open source projects’ security is that big tech companies will not easily accept having to spend their profits on security efforts that do not just benefit themselves. Proprietary firms do not feel that using open source code is a commitment to the community of users and buyers of their software and hardware. Not only do they not practice any accountability back to open source, they benefit massively from the contributions and code of others for free.

Rules and Regulations

Apache Software Foundation

While the general intentions of Europe’s Cyber Resilience Act (CRA) and Product Liability Directive (PLD) are welcomed in general–and their much-needed bolstering of security in particular–we are concerned by the proposed specifics. Proposed regulation imposes obligations too early in the supply chain, risking stifling innovation and jeopardizing the ability of open source organizations, such as the Apache Software Foundation, to make a positive contribution by coordinating the downstream industry with regard to security.

Rust Foundation

Funds for the support of OSS will require international disbursement with minimum bureaucracy in order for those funds to be allocated appropriately and to generate the desired impact. Any financial contribution or investment frameworks developed to funnel funds towards this work must ensure that they are free from substantial bureaucracy or restrictions.

GitHub

International collaboration can multiply the impact of federal government activities across all open-source software security priority areas. As with other global challenges and public goods, national governments share common interests in security, even among competitors. Each of the areas identified by the RFI should be on the agendas of most national governments. US diplomacy should encourage other national governments to increase and coordinate investments in open-source software security, utilizing the motion itself to build trust, as well as increasing global resilience by decreasing cyber risk.

MITRE's Center for Data-Driven Policy

The U.S. government should work with and lobby the European Union to modify the current draft language of the CRA to ensure these developers are protected from liability. If we fail to do so, and the CRA is passed with the current language, then the negative effects on the U.S. and global FOSS ecosystem may be substantial.

RTX Technology Research Center

The United States should collaborate with the European Union on the Cyber Resiliency Act to seek standardization of terms such as “Critical Class I/II” and “Critical Infrastructure.” This will enable greater collaboration across international supply chains.

Sonatype, Inc.

We must collaborate with other governments and security agencies to ensure future regulations and policies prevent fragmentation within the OSS ecosystem. OSS is a public good; the contributors and custodians of this public good that underpins all software must be protected and supported through thought policy and regulation.

The US Government, Open Source Software and Analyzing 786 Pages of Responses - Results

Serkan Holat — Thu, 07 Dec 2023 15:31:41 +0000

A semi-professional content analysis on the submitted responses to the US Government's Request for Information on Open Source Software

Part I: Results

In August, the US Government issued a public call in the form of a Request For Information (RFI) regarding open source software. The objective was to seek input from private and public sectors and start formulating a long-term strategy and action plan for the federal government to strengthen the open source ecosystem.

Here is an excerpt from the official press release:

In addition to its many benefits, the ubiquity of open-source software in commercial products, government systems, and military platforms presents unique security risks. For this reason, the White House established the Open-Source Software Security Initiative (OS3I), an interagency working group with the goal of identifying policy solutions and channeling government resources to foster greater open-source software security across the ecosystem. By working with other interagency partners, OS3I identified several focus areas, including

(i) increasing the proliferation of memory safe programming languages;

(ii) designing implementation requirements for secure, privacy-preserving security attestations;

and (iii) identifying and promoting focused areas for prioritization.

For more detailed information about the RFI, you can refer to the following link:
Request for Information on Open-Source Software Security: Areas of Long-Term Focus and Prioritization

National Public Fund to Finance Open Source Ecosystem

As a dedicated advocate for Agile Public Funds, I took the opportunity to contribute by submitting a 'National Public Fund to Finance Open Source Ecosystem' proposal to the RFI.

Briefly, considering OSS falls under the public good category and its global consumption leads to the well-known Free-rider problem:

Can we establish dedicated funds to overcome coordination issues?
And can we design these funds tailored to the fast-paced nature of these new digital public goods?

Below is the Principles section for the Scalable Public Funds:

Proactive: The fund should proactively identify and evaluate eligible open source initiatives, reducing bureaucracy and uncertainty.
Scalable: The fund should be designed to scale, accounting for the continued growth of the open source ecosystem.
Data-Driven: Resource allocation should rely on objective metrics, ensuring unbiased distribution.
Transparent: The evaluation criteria, metrics, and weights should be publicly accessible.
Continuous: Acknowledging the ongoing contributions of the OSS to the economy, the fund should commit to generating constant revenue rather than one-off payments.

To review the proposal, you can visit the following link:
National Public Fund to Finance Open Source Ecosystem

An Inevitable Analysis

The RFI has become an invaluable repository, collecting insights totaling 786 pages from 107 organizations and individuals across the industry, including major technology companies, foundations, research centers, and security firms. The fact that these public responses were limited to roughly ten pages turned out to be a convenient detail.

As a result, my initial interest in identifying reactions related to my proposal inevitably shifted into a semi-professional, purely manual content analysis.

Results

Let's start with sharing the Results document, which should speak for itself:
ONCD-2023-0002 - Content Analysis

Quick items about the document:

The "Notes" of each column contains the descriptions and alternative keywords.
If available, the "Notes" of a cell includes the paragraph related to the keyword.
✖ indicates "False positive" or "Not applicable".

Methodology

All responses were converted to PDF and organized under a folder on Google Drive. Utilizing Google Drive's full-text search functionality proved more efficient than relying solely on the Regulations website.

Feel free to refer to the Google Drive folder and download the responses:
ONCD-2023-0002 - Content Analysis - Responses

Steps

Here is the list of steps I took to produce the results.

Start with a text search on Google Drive.
Mark the responses in the sheet.
Review the marked responses.
Determine True/False positives and categorize results accordingly.
Take note of Highlights and newly revealed keywords during the review.
Iterate through the steps to improve the coverage.

No ChatGPT 🤷‍♂️

While ChatGPT could have been an excellent tool for analysis and categorization, the initial focus was on identifying and reviewing similar responses, and the analytical part unexpectedly evolved. When it became clear ChatGPT could be handy, I had already completed most of the work and didn't want to integrate it in the later stages to maintain consistency. So, next time, Chad!

Categories & Keywords

Below is the list of the categories, associated keywords, and how many different responses they appear in. In the document, please check the "Notes" of each column to see the details and alternative keywords in the document.

Definitions: Which keywords does the response refer to when describing OSS?

Volunteer: 22 responses
Public good: 14 responses

Solutions: Which solutions does the response recommend?

Government funding: 37 responses
Procurement: 8 responses
Tax credits: 7 responses
Government OSPO: 4 responses

Systemic issues: Which systemic issues does the response mention?

Underfunded: 12 responses
Free rider: 6 responses
Bureaucracy: 4 responses
Cyber Resilience Act: 11 responses

Organizations: Which organizations does the response mention?

OpenSSF: 23 responses
OWASP: 12 responses
Sovereign Tech Fund: 10 responses
Open Technology Fund: 7 responses
Open Source Initiative: 6 responses

Quick Takes

I may write follow-up articles to expand my findings about the analysis, coupled with specifics of why we should establish dedicated public funds to finance open technologies and challenges around these initiatives.

For now, I will briefly share my initial remarks about the results.

Growing Demand for Public Funding

Compared to the previous conversations on financing open technologies, it is promising to see public funding being promoted as a feasible solution by numerous organizations. Degrees and conditions vary, but out of 108, 37 responses suggest government funding as a way to strengthen the open source ecosystem, including big tech companies like Amazon, Google, and Microsoft.

Following these recommendations, it may not be a surprising outcome if the US Government decides to form a dedicated public fund for open source – a significant impact on the ecosystem.

Charity or Business

On the flip side, open source software is still predominantly defined as volunteer work rather than potentially a business activity that generates substantial economic value. The term "volunteer" or alternatives appear together with open source software in 22 responses—similarly, only a few mention open technologies' social and economic benefits.

This outcome might be understandable since the RFI primarily focuses on security. Still, is it a sign that we should work on our elevator pitch for open tech across the board and emphasize its connections with real-world challenges?

Successful organizations

Under the Organizations category, The Open Source Security Foundation (OpenSSF), established under the Linux Foundation only three years ago, stands out prominently. Undoubtedly, the RFI is perfectly in line with its scope, yet it was mentioned in 23 responses numerous times, making it the most referenced organization.

Similarly, despite being just one year old, the Sovereign Tech Fund has been cited as a model in almost all instances where dedicated public funding has been proposed.

A closer look at the ingredients of these organizations might be good homework, giving us valuable insights.

Potential Improvements

Once you start digging such a mine, you constantly conjure new ideas. These are my notes on potential updates to extend the analysis.

Demographics of Response Owners:
- Include a breakdown of response owners' demographics, determining individuals, foundations, universities, and corporations.
Collect Links for Referenced Sources:
- Gather links mentioned in the responses to identify the most referenced sources.
Expand Categories:
- Introduce the "Incidents" category together with notable events, such as "Log4Shell," "Heartbleed," or "Solarwinds."
- Introduce the "Digital Infrastructure/Software Supply Chain" keywords under the "Definitions" category.
- Introduce the "Central Software Inventory" keyword under the "Solutions" category.
Optimize Existing Keywords:
- Improve the "Bureaucracy" by including additional keywords such as "regulations" and "mandates" for a more extensive analysis.
- Restructure the "Volunteer" keyword into "Who is Producing and Maintaining OSS," and improve the clarity by identifying Volunteers, Foundations, and Corporations.
- Refine the "Government Funding" category to address items falling on either the "Strong" or "Weak" sides for better categorization.

Highlights

You can continue with the second article, where I share over forty highlights that got my attention while reviewing the responses. It's a compilation of quotes from 25 organizations, including major technology companies, well-known foundations, universities, and security firms.

Feedback

As usual, your feedback is priceless! Do you have any suggestions or questions? Please don't hesitate to share them under this article or directly in the document.

Open Source Public Fund experiment - One and a half years update

Serkan Holat — Thu, 27 Jul 2023 11:27:20 +0000

Unresolved question: How should open technologies be financed?

When it comes to open technologies, such as open source software, there is a long-standing debate about how to finance them and by whom.

My humble conclusion is straightforward. Expecting thousands of companies to contribute back to the ecosystems they consume without coordination is a hopeless dead end. Open technologies fall under the public goods category; therefore, we should finance them with public money, similar to public roads, bridges, or libraries.

However, the nature of open technologies is pushing us to innovate over our funding models; even though we should recognize them as a new type of digital, public goods, they are produced by the private sector, which is a combination that happens for the first time on a large and continues scale.

This unique state brings us a new challenge; developing a scalable public funding structure to finance an entire and ever-changing market.

Last year, I started an Agile Public Fund experiment to dive into the practical side of this challenge; study and demo a funding algorithm that distributes a certain amount to open source initiatives based on criticality and usage metrics. The journey continues with new allies, some updates, and with more challenges to come.

As usual, your feedback is priceless; don't hesitate to get in touch with any comments, questions, or ideas.

Updates

I had a chance to improve the data, process, and algorithms in the last couple of weeks. You can see all the changes on the Open source public fund experiment document on Google Sheets.

TL;DR: I could extend the Criticality Score algorithm with usage metrics from Ecosyste.ms API and apply it to all open source accounts under the Open Collective, so we have a new ranking now! I also made it possible to change the weights of each parameter so that you can try the algorithm by yourself.

Open Collective data refresh

Refreshed the accounts list from Open Collective API and included the country and yearly budget in the data. There are now 4729 accounts with a code repository.

Criticality Score's latest version

Updated my local Criticality Score repository to the latest version. The new version is written in the Go language instead of Python, and it has a second algorithm that calculates the score by getting the "dependent count" data from the Open Source Insights (deps.dev) API.

Manual score calculations

Recreated all formulas for calculating the scores under the "Criticality Score - Results" sheet. Now it is possible to play around with the weight of each parameter and see the new results directly within the document.

New config with the Ecosyste.ms data

Decoupling the data collection and the score calculation made extending the data from other custom resources easy. Thus, I retrieved each repository's "dependent_repos_count" data from the Ecosyste.ms API and created a new algorithm configuration. This one replaces the deps.dev's "dependent count" parameter.

Now there are three different algorithms for score calculation, and you can see their parameters under the "Criticality Score - Config" sheet:

original_pike - Yellow: The default algorithm from the Criticality Score.
pike_deps.dev - Green: The second algorithm from the Criticality Score includes the "dependent count" from deps.dev as an extra parameter.
ecosyste.ms - Blue: The new algorithm that uses the "dependent_repos_count" data from the Ecosyste.ms API and replaces the deps.dev's "dependent count" parameter.

Changing a parameter under the Config sheet updates the scores under the Results. Feel free to copy the document and try it yourself.

Stats

Under the new Stats sheet, you can see a quick overview of the data in the other sheets:

General stats of the Open Collective accounts and repositories
Budget stats of the accounts
The languages of the repositories
The licenses of the repositories
The countries of the accounts
The ecosystems of the repositories
Top 10 repositories of each algorithm

Winners

This sheet shows the history and the details of the three winners I randomly choose monthly to test the algorithm.

Budgets

I plan to follow the budget changes of the Open Collective accounts in time under this new sheet.

The process and the helper tools

Below is a brief list of actions to prepare the data and the final results. One critical remark is that currently, the process only works with GitHub repositories, so I exclude non-GitHub ones—hopefully, a detail to improve in the future.

Retrieve the accounts data from Open Collective API to create Accounts and Budgets sheets,
Call GitHub API to find the most starred repositories of each GitHub user, which you can find under the "GitHub - Top repos" sheet,
Run the Criticality Tool to get the data points of each repository, which are stored under the "Criticality Score - Results" sheet,
Call the Lookup endpoint of the Ecosyste.ms API to get the additional "dependent_repos_count" data of each repository and combine it with the other parameters under the "Criticality Score - Results" sheet,
Once the data is in place, the existing formulas in the "Criticality Score - Results" sheet calculate the scores.
Last, I will be updating the data and the scores once a month.

Quick links:

Stats overview

Here are some stats that stand out:

The total number of Open Collective accounts with a code repository is 4729.
96.32% of those accounts use GitHub as their code repository.
However, 15.38% of the GitHub username are not valid / don't exist, which is a massive number. It would be handy if Open Collective could add a code repository/link verification method or ask the users to update their profile details occasionally.
81.62% of the accounts use USD as their currency. Their yearly budget is about $15 million, and the average is $3,887 per account, probably not even one percent of the ideal figures.
The language of almost one-third of the repositories is JavaScript. Python comes second, and PHP is third.
MIT dominates the license list with 41.91%, of which there are 27 different licenses. 15.41% of the repositories don't have any.
Regarding the accounts' countries, the United States leads the list with 11.4%. China follows with 2.9%, the United Kingdom at 2.8%, Germany at 2.7%, and India at 2.5%.
The Ecosyste.ms search returns 1453 matches out of 3336 unique repositories. Out of this data, npm is the top ecosystem with 46.94%, go is the second with 13.35%, and PyPI is third with 9.70%.
And last, here are the top five repositories with the highest criticality score based on Ecosyste.ms config:

You can see the full ranking of each algorithm and more under the Stats sheet.

Winners overview

I randomly choose three open source collectives from the accounts list every month to test the algorithm results and reach out to the open source entrepreneurs. I distribute an amount to each collective based on their scores.

Since the start, it's been 19 rounds, and using experiment as my excuse, I have proudly invested $4259 in 57 open source collectives.

As a side experiment, I determine the amount to distribute based on new social media followers. Six months ago, I included Mastodon and LinkedIn next to Twitter and gained 178 followers on all three platforms since then.

What's next?

In short, a lot! Next to telling a more compelling story about why we should invest in open technologies and why public money is the best option to achieve that, there are many practical items on the list:

Most under-appreciated: Find the accounts with the highest score and minimum yearly budget,
Permissive the better: Categorize permissive and copy-left licenses and add a license parameter to the algorithm as an experiment (feedback is welcome),
Repositories vs. releases: Combine the repository data with their release information and improve the algorithm by including the release metrics.
National public funds simulation: Categorize the accounts based on each country and simulate fund distribution per country.

Thanks for tuning in, and I hope you enjoy the ride as much as I do. Wish me luck, and see you next time!

Open Source Public Fund experiment

Serkan Holat — Mon, 03 Jan 2022 14:18:00 +0000

One-year review - LinkedIn | Mastodon
Six-month review - Twitter

Question: You have 100 money. How would you distribute this amount across the entire open source ecosystem?

Motivations: Free and Open Source World

For over two decades, I have been working across different industries, helping companies develop primarily internal but always proprietary software solutions, which is long enough to recognize the inefficiencies of closed technologies at scale.

One practice that was relatively easy to observe is the development of similar applications in different companies, a collective habit that leads to the constant reinvention of the wheel.

On an individual basis, it is logical for companies to keep the output of their investment to themselves. However, once that behavior becomes a pattern among all companies producing technology, it becomes an obstacle to reusing existing solutions. Short-term individual gains lead to collective losses.

This realization made me curious about open source software. I have spent the last few years researching its sustainability, focusing on business and funding models.

I envision a future where we collectively build most of our technology solutions in the open, whether software, hardware, AI, or otherwise. A scenario in which companies and individuals constantly reuse and innovate each other's work. How would minimizing repetitive solutions and combining expensive engineering resources impact our technological progress and societal challenges, such as achieving the United Nations' Sustainable Development Goals?

However, a missing ingredient in achieving this future is aligning incentives for businesses to keep contributing to the open technology ecosystem.

Since I want to keep this article short and focused on the experiment, here is a summary of my conclusions:

* Open technologies, such as open source software, generate substantial value for our economies and require a steady stream of revenue in return.
Due to coordination issues and lack of contracts, the businesses that consume open technologies cannot return that revenue to the ecosystem, a.k.a. the Free Rider Problem.

As a solution, we should,

Recognize open technologies as a new type of digital public good,
Finance the ecosystem by setting up national or global public funds and generating a direct income for organizations producing open technologies based on their products' usage and criticality metrics,
And aim to establish a financially sustainable digital public goods market in the long run.

Agile Public Funds

To achieve scalability in this structure, our public funding models must align with the unique characteristics of these new digital goods.

Traditional funding options, such as one-time grants, may work well for single, long-term projects but are unsuitable for a fast-paced ecosystem like software development.

Instead, we should establish scalable public funds that distribute resources across the entire ecosystem, evaluating each solution's past success using specific metrics.

I aim to study and demonstrate the practicality of an Agile Funding model through this personal experiment.

Process

I have created a document containing all available open source collectives:
Open source public fund experiment

With your help, I will randomly choose three open source collectives every month from this list.
Find each collective's "most popular" repository on GitHub by using the number of Stars. I want to pick a single repository only to keep the process simple.
Calculate each repo's score and weight using the Criticality Score tool.
Distribute that month's amount to the projects based on these results through Open Collective, preferably on the first day of each month.

I will keep updating the document in the coming period, so please check it to see the selected projects, scores, weights, and final amounts.

Monthly Amount

I will tie the monthly amount to the new follower count to keep the numbers dynamic and invest a certain amount for each follower. You can check the document to see how I calculate the amount for each month.

Criticality Score

I will use the Criticality Score tool from the Open Source Security Foundation (OpenSSF) as a base, calculate a score for each selected project, and distribute our small fund based on the results.

I plan to improve the contribution algorithm in time. It is important to note we currently miss the "usage" parameter of open-source solutions, which is another crucial parameter we need.

For more information on the Criticality Tool, please check its repo.

Open Collective

Open Collective is a platform that provides legal and financial support for grassroots communities, including for a large number of open source projects. Its transparent structure makes it easy to verify the payments, so I chose to use it as a payment platform.

I retrieve the "accounts" data from their public API and process the rest based on this dataset.

Quick links:

Don't hesitate to ask me any questions about the data, tools, or the process.

Feedback

As usual, please feel free to share your thoughts and questions. I will do my best to improve the process based on your feedback.

DEV Community: Serkan Holat

The US Government, Open Source Software and Analyzing 786 Pages of Responses - Highlights

Topics

Current State

Facts and Figures

Most Important Area

Public Funding

Ideas and Insights

Let's Be Frank

Rules and Regulations

The US Government, Open Source Software and Analyzing 786 Pages of Responses - Results

National Public Fund to Finance Open Source Ecosystem

An Inevitable Analysis

Results

Methodology

Steps

No ChatGPT 🤷‍♂️

Categories & Keywords

Quick Takes

Growing Demand for Public Funding

Charity or Business

Successful organizations

Potential Improvements

Highlights

Feedback

Open Source Public Fund experiment - One and a half years update

Sponsored by

Unresolved question: How should open technologies be financed?

Updates

Open Collective data refresh

Criticality Score's latest version

Manual score calculations

New config with the Ecosyste.ms data

Stats

Winners

Budgets

The process and the helper tools

Stats overview

Winners overview

What's next?

Open Source Public Fund experiment

Motivations: Free and Open Source World

Agile Public Funds

Process

Monthly Amount

Criticality Score

Open Collective

Feedback