Open source subsidy program

[epicfaace]

Discuss @coni2k 's proposal (https://github.com/PlaintextGroup/oss-virtual-incubator/blob/main/proposals/open-source-subsidy-program.md).

[coni2k]

According to OpenForum Europe, the cost-benefit ratio of open-source software is 1:4. Taking this as an input, here is a basic cost-benefit ratio calculation for the subsidy program without counting the overhead.

For example, if we could convince companies to turn their proprietary solutions to open source software with a 10% subsidy level, the cost-benefit ratio would be 1:40.

That would mean generating $200.000 economic value by $5.000 subsidies for a project that costs $50.000 to develop.

Subsidy level	Cost-Benefit Ratio 1:x	Example Development cost	Example Subsidy amount	Example Economic value
100%	4	$50,000	$50,000	$200,000
50%	8	$50,000	$25,000	$200,000
25%	16	$50,000	$12,500	$200,000
20%	20	$50,000	$10,000	$200,000
10%	40	$50,000	$5,000	$200,000
5%	80	$50,000	$2,500	$200,000

Google Sheets:
https://docs.google.com/spreadsheets/d/16oRsO9nn0NfRUgwE0u6rCeyFj9N4N5qA2_nKWtARxwc/edit?usp=sharing

[epicfaace]

@coni2k My major questions:

• Wouldn't creating a "Development activity threshold" for a project to receive funding (such as X number of releases) create perverse incentives? For example, a project might artificially inflate commits or releases to get more funding. Also, number of commits ≠ amount of work done.
• Why would a subsidy program just focused on enterprises be justified or even popular, given that there is a current power imbalance between enterprises and unpaid individuals in the OSS ecosystem?
• Why aren't companies already incentivized to turn proprietary software into OSS? I assume that's because they have other overriding concerns (such as IP) -- what reason do we have to believe that would a subsidy would overcome this?
• To accomplish the goal of making more enterprises adopt OSS, why is a subsidy program superior to alternative approaches such as: let the market sort it out (see https://www.wired.com/2016/08/open-source-won-now/ and https://techcrunch.com/2019/01/12/how-open-source-software-took-over-the-world/), increase OSS education for companies, changing government procurement policies to favor OSS (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3355486)?

[coni2k]

@epicfaace, thank you for your questions!

I will do my best to answer each. However, since my answers will be long, I reply to the questions separately; I hope they will be easy to follow.

Question: Wouldn't creating a "Development activity threshold" for a project to receive funding (such as X number of releases) create perverse incentives? For example, a project might artificially inflate commits or releases to get more funding. Also, number of commits ≠ amount of work done.

These concerns are precisely the areas that we need to study. We aim to answer whether we can create a standard and healthy way to measure development activities.

First, our approach should look at the total development activities, not a single parameter like only commits.

For example:

• Lines of codes: Is the codebase getting larger steadily?
• Output file sizes: If there's an output, does the file size increase steadily?
• The number of new/closed issues: Is there any backlog, and how often does this backlog change?

These parameters will have a certain weight in calculating the development activities. And, at the end of the study, we might give very little, or no importance to the commit frequency, which I agree is not a reliable metric.

On the other hand, we should always assume that the participants will try to game the system, and our efforts to avoid this would be a considerable chunk of the overhead.

To avoid gaming the system:

• We should increase the size of the subsidy gradually. The size should only increase once we reach certain maturity and confidence levels. The primary strategy here should be that the size of the subsidy should stay lower than the energy it requires to game the system.
• We should develop ways to flag unusual activities automatically.
• We should monitor the system with these automated flags and manually when necessary.
• If we conclude a company is deliberately gaming the system, we should remove the company from the program.

For us, the question will remain the same; considering all the overhead, is it possible to have a healthy subsidy program that has a higher cost-benefit ratio?

[coni2k]

Why would a subsidy program just focused on enterprises be justified or even popular, given that there is a current power imbalance between enterprises and unpaid individuals in the OSS ecosystem?

This program aims to expand the open-source ecosystem and its culture within the software industry.

Our motto could be, "No solution should be developed twice", let alone multiple times. The main focus is to consolidate engineering resources.

Hence, we address a fundamentally different problem with this program than unpaid open-source software maintainers.

I don't necessarily see the power imbalance as a problem. We will increase the number of paid professionals developing open-source software through this program, and the companies will become natural sponsors of these developers while scratching their itch.

In other words, the number of unpaid open-source developers, at least as a ratio, will technically decrease.

Increasing the number of companies and developers producing open-source software should also improve awareness about the benefits of open-source software and make it easier to develop even more ambitious programs (e.g. Universal/direct income for open source maintainers)

[coni2k]

Why aren't companies already incentivized to turn proprietary software into OSS? I assume that's because they have other overriding concerns (such as IP) -- what reason do we have to believe that would a subsidy would overcome this?

To answer this question, we can look at the definition of a market failure:

"In market failure, the individual incentives for rational behavior do not lead to rational outcomes for the group. In other words, each individual makes the correct decision for themselves, but those prove to be the wrong decisions for the group."

In our case, each company is protecting its intellectual property, which is a correct decision individually. However, this proves to be a wrong decision for the entire software ecosystem.

Since no company shares its solutions, we start losing collectively by spending our (engineering) resources to reinvent similar solutions. We should also note the missing innovation possibilities and other benefits of open source software.

I'm sharing this primarily as my first-hand observation as someone developing software solutions for more than two decades. On the other hand, it could be interesting to back this up with a study that looks explicitly into the software industry from this perspective.

Is it possible to understand how many unique or similar solutions we are developing and the overlapping investments from different companies?

If we could answer these questions, it could be easier to discuss the necessity of a subsidy program. So, please let me know what do you think about this.

Why can subsidies change the companies' overprotective habits?

Our initial goal is for companies to share their non-essential solutions. The company may not lose any competitive advantage if they share these solutions; however, they also don't benefit immediately. Again, the main benefit is to the entire ecosystem.

Therefore we can use subsidies to incentivize companies to consider sharing their solutions. Because they will have a financial gain by covering some of their development costs, now it can be worth the effort, while the whole group also wins.

[coni2k]

To accomplish the goal of making more enterprises adopt OSS, why is a subsidy program superior to alternative approaches such as: let the market sort it out and, increase OSS education for companies, changing government procurement policies to favor OSS?

We need the "Software ecosystem map" study precisely for this reason. We should support and try all these alternative approaches and see which one moves the needle in the open source and proprietary software ratio.

[coni2k]

One more addition to the first question/answer; we should remember that the whole process will be open to the public; it will be transparent and open source.

Anyone can inspect who's receiving subsidy in exchange for what type of work, making it more challenging to abuse the system or making it easy to receive feedback to improve the system.