Beyond the Dichotomy of Open-Source and Corporate Worlds

A View on Software Development in the Next Decade

Jinglei Ren
Persper Foundation
6 min readAug 9, 2018

--

[This is a narrative of our talks at MIT and Harvard on July 16–17. Our slides are here.]

(Brian A Jackson/Shutterstock.com)

Two years ago, I faced the dilemma of working for a company or for an open-source software library. I wanted the true freedom and openness in the open-source world, but I cannot risk a company salary as I have two children to raise.

The freedom to work for an open source project is not just a personal affair. The serious Heartbleed Bug with a massive impact revealed how a poorly funded and maintained open source library can “make you bleed”. The author of Octave, a popular scientific computing engine, and a core maintainer of PulseAudio, the default sound server for most Linux desktops, are just two examples of many open source developers that struggle financially to contribute to their beloved projects.

So, can we get the best of both the open-source world and the corporate world?

Why the Dichotomy of Open-Source and Corporate Worlds?

We see the power of two economic concepts that give compelling explanations of the dichotomy.

(CC BY 4.0)

Information asymmetry. Users do not know what developers are doing, and individual developers lack a global view of everyone’s contribution. So, who can decide the value allocation among developers? People resort to one of the following two methods: (1) build the hierarchy and bureaucracy of a company to allocate value, even though this is far from being fair and efficient; (2) give up on the value to avoid the allocation issue, as is done in most open source practices. The former is the corporate approach, and the latter is the open-source approach.

(Michael D Brown/Shutterstock.com)

Contracting costs. To enable transactions, each user has to contract with every developer that contributes code; all the developers have to contract with each other, negotiating how to share IP and royalties. Even worse, developers could quit, and new developers could join; users come and go, too. So, people reduce the costs by one of the following two ways: (1) create a legal person (i.e., a company) as an intermediary so that every developer or user only needs to form one contract with the legal person; (2) simplify and unify all contracts into one simple open source license, sharing copyright mostly for free but sacrificing more beneficial contractual relationships. The former constitutes the basis of corporate companies, and the latter constitutes the basis of open source projects.

In summary:

Both corporate and open-source development processes are indeed compromises with information asymmetry and contracting costs.

While software developers create valuable intellectual property (IP), they receive returns that do not match the value they create. A major portion of the value is either exploited by unnecessarily cumbersome companies or relinquished through open source code.

With the right techniques to directly address information asymmetry and contracting costs, we could achieve a solution that merges corporate and open-source benefits with fewer compromises. This would change the paradigms of software development and innovation in the future.

Measuring Code Contributions

To resolve information asymmetry, we need a tool to measure the contributions of developers. Measurement is a fundamental topic in many areas. Physicists spent 90 years increasing the accuracy of time measurement from six parts per million to one in the 18th power of 10. Society and the market constantly, dynamically, and collectively determine the prices of goods. While time is objective and prices are subjective, the Google search engine combines both patterns to measure the relevance and importance of web pages. It’s been nearly 20 years since the initial PageRank algorithm of Google was published. Now, is it time to exert some effort on measuring the value of code contributions?

Recently, our short paper entitled “Towards Quantifying the Development Value of Code” was accepted to FSE 2018, a top conference on software engineering. We analyze both structural and non-structural value of code, leveraging latest program analysis and machine learning techniques. Hezheng will elaborate our algorithms in another article (follow us on twitter to get cutting-edge insights).

When Shareholdings Meet Open Source Projects

To materialize the measurement results, we introduce an intellectual shareholding concept to open source projects. A developer contributes to a project and earns project shareholdings calculated by our algorithms; then, project revenue such as donations or sponsorships is distributed to developers according to their shareholdings (i.e., contributions).

Linus’ Law: Given enough eyeballs, all bugs are shallow.
— Eric S. Raymond, The Cathedral & the Bazaar, 2001.

This new model can bring fair and long-term rewards to open source developers. Traditionally, only a few core developers receive sponsorship through Patreon or Tidelift. But open source development is about community. The creator of vue.js, a most popular front-end framework, once described the allocation problem in an interview. The project shareholding model realizes a wider and fairer distribution of the income to most of the contributors. It increases the incentives for contributions and encourages the community to thrive.

The Ultimate Vision

The present shareholding company system, established in 1600s, enables capitals to collaborate, share returns, and make long-term investments, releasing tremendous productive forces. In the last two decades, Linux has proven that complex software can be developed by a loosely coupled community. Based on these successful practices, we hope to build a new shareholding system for intellectual property that can enable talent to openly collaborate, capture financial returns, and invest effort for the long term.

The most important feature of Linux, however, was not technical but
sociological.
— Eric S. Raymond, The Cathedral & the Bazaar, 2001.

We are working with Orrick, a leading US law firm, to build a legal framework (licenses, user agreements, terms of service, etc.) to realize both flexible semantics and low contracting overhead. Project founders simply specify a few parameters and our platform will generate all necessary legal documents (plus smart contracts if the founders believe in the blockchain technology) and set up proper payment channels for the project. Essentially, a company is a collection of contracts. Our framework aims to mimic a virtual company that is open to all developers and users and that is owned by those who make contributions.

Such an open virtual company inherits two favourable properties of intellectual shareholdings, meritocratic value allocation and long-term returns. In a traditional company, you might work harder than your colleague but earn the same amount of money, or even less because that person is good at inflating presentations and your manager never read your solid code. Moreover, if you quit a job, your salary would cease, although the company would continue to make money from your code. With intellectual shareholdings, developers continue to receive an expected income even if they stop working for a project or if the project only generates profit in the following year.

By combining our two techniques, developers can avoid a traditional company and its inefficient hierarchy, rigid salary system, and strict IP boundary. Note that non-code contributions can fit into our new model as well. A project can reserve a percentage of shareholdings or revenue for visionaries or outsourced financial and marketing vendors, for example. An open virtual company can be profitable like a traditional company and organize the development process like an open source project. Developers would enjoy more freedom to work for what they love and master.

Application to Real Projects

We plan to test our code contribution measurement in prominent open source projects and observe how the community reacts to the change of income allocation. Our plan is as follows:

  • Collaborate with a few already well-sponsored open source projects and change their income allocation method for 3 months.
  • Sponsor a few open source projects for 3 months using our income allocation method.

If you like our idea, please support us by simply subscribing to our mailing list for updates!

If you are interested in applying our income allocation scheme to your projects, please do send us a message at contact@persper.org! We greatly appreciate your help!

[Finally, I call your attention to our efforts to build an independent platform to support the whole solution: a decentralized GitHub for sharing code value.]

--

--