Open Source is the infrastructure of business, but the economic structure of Open Source is one of resource extraction like logging or mining: many businesses extract wealth from Open Source, but do not return significant value to the developers. To avoid unconstructive dispute, we avoid mentioning the companies and organizations, but the informed reader should be able to connect the dots.
Paid support is put forth as a means for the developer to produce income, but is ill-matched to the customer. The developer generally forms a company that services one Open Source program, the one they develop. A corporate user might have 100 Open Source programs that are critical to their business, and thus would be in the unenviable situation of having to isolate an issue to one of those programs and convince the vendor that it’s their problem, while various support vendors point fingers at each other. This has been very advantageous to companies like IBM, which offer to service all software, and thus get the service contract while the smaller Open Source company does not.
This leaves both the developers and users in a precarious situation: a developer with the entire Fortune 500 for customers is often completely uncompensated and under severe economic pressure. One such developer passed responsibility for their software to, unknown to him, a bad actor with probable nation-state support. That entity inserted a back-door which could have caused a breach of most companies and web sites on the Internet if it had not been discovered in time.
The Open Source developer is poorly equipped to handle new laws such as the EU Cyber Resilience Act. Intermediaries are taking advantage of this as another means to divert funds from the Open Source developer, because they can vend a regulation-compliant copy of the developer’s software, while the developer can not.
Open Source has not reached the common person. The general population mainly use Open Source software only as a hidden infrastructure component of proprietary platforms by Apple, Google, Microsoft, etc. Indeed, Open Source provides the infrastructure for surveillance and even exploitation of these users in the interest of the platform providers. The common person may be vaguely aware of the Open Source concept through efforts like Wikipedia. But few software creators, other than Open Source, would actually operate in the interest of that user rather than the interest of a large company that mainly benefits by surveilling that user. Thus, Open Source has much to offer the common person if we can reach them. But the common person doesn’t generally choose software on a philosophical basis. They pick the platform that best meets their immediate needs. Thus, we must create software that is more attractive to them than that of the big companies. The absence of deliberate surveillance is potentially an attractive feature, and we can add branding to promote that, but the software must provide esthetics and functionality equal to or better than the competition if it is to win the user.
The problem is that Open Source developers mainly write software for themselves and people like them. A few projects, like LibreOffice and Firefox, have been better at reaching the common person, but these projects use paid developers, who thus have different motivation than the uncompensated Open Source developer.
Open Source can’t address its legal problems. Software Freedom Conservancy knows of over 1000 companies that have not complied with the licenses of Open Source which they use in commercial products, and can only prosecute a few. This rampant infringement is demoralizing for developers.
Compliance is difficult for business, with large businesses known to have spent as much as USD$7 Million per year on Open Source compliance. Can’t we make compliance easier and give them something better to do with that money?
What To Do?
Given this list of issues, especially the almost-universal diversion of funds which should go to the developer, we can fairly ask: Why does the Open Source developer put up with this? The lucky developer gets to produce Open Source on salary for some employer and doesn’t worry about being compensated for their work. But many are unfunded, and many of those folks have already stopped producing Open Source in the face of abuses.
The independent developer is critical because they have much greater latitude to invent rather than to fulfill a well-formulated corporate agenda. Invention often requires the investment of time into something that isn’t guaranteed to produce a return, and most employees are not part of a research department where they have the freedom to chase wild geese.
It’s notable that the web came from an Open Source developer for CERN, the nuclear-research facility, who was salaried, encouraged to research and able to depart from his employer’s nuclear-research agenda. Similarly, many of the most important advances in Open Source have come from the independent developer, who writes his own agenda.
We must address the problems of the key community of independent Open Source developers, and encourage more developers to take this path, or eventually lose them and their innovation. Post Open provides a way to pay for their work.
We believe that Post Open can address the issues of Open Source and build a much healthier community that addresses these problems and meets goals that Open Source fails at today.
Thus, we establish some goals for Post Open:
- Make it easy for the Open Source developer to transition to Post Open by dual-licensing their work as both Open Source and Post Open. The paid user of Post Open pays for the entire Post Open collection, and thus pays for dual-licensed Open Source and software that is exclusively under the Post Open license.
- Redirect funding to developers through dis-intermediation. Provide an entity that developers own which identifies them, operates security processes, provides the software and paid support to users, collects license fees and distributes revenue to developers.
- Handle the requirements of new law, for example the EU Cyber Resilience Act, on behalf of all developers in the Post Open Collection.
- Don’t dilute the Open Source brand. Post-Open will never call itself Open Source, because it has different rules. The Post Open license actually enforces that.
- Preserve software freedom for individuals and small business. They get the software for free, and with similar rights to those of Open Source.
- Deep-pockets entities (over USD$5 Million revenue in a year), companies that include the software in a paid-for product, and companies that wish to keep modifications private must pay. Unless they publish enough contributions to the Post Open Collection, in which case we pay them.
- Compliance simplicity: once a year, paid users account for their revenue and their use of software in the Post Open Collection, and pay a small portion of their revenue (we’re considering 1%) for all Post-Open software, not just one program. Then compliance is over until next year.
- Licensing simplicity: One zero-cost license, one paid contract which includes the zero-cost one by reference, one operating agreement between all of the developers.
- Privacy: all compliance information and the amount of the payment from companies is under NDA, data and payment is sequestered to a CPA firm rather than provided to the overall organization. The public organization sees totals (use of a program, revenue, etc.) rather than your private data.
- Pay developers fairly for their work. Make it possible for an individual developer to stay at home and code all day, and make their living that way without having to build a company. Apportion payment to developers based on software use by paid users and the size of their contribution to that software.
- Improve security and quality by reliably identifying developers, providing proper funding for developers to maintain their software, provide cryptographic-hardware-backed authentication and secure software chain-of-custody.
- Service all Post-Open software through one entity and share profit with developers. Developers maintain their own software rather than operating the front-line service organization.
- Fulfill the software needs of non-technical people, a job that Open Source mostly fails at today. Pay developers, because software that is used for free by individuals and small entities will also be deployed by richer companies that are paid users.
- Collect fair payment from providers and users of software-as-a-service and manufacturers of embedded systems.
- Reverse the power differential of Open Source, where deep-pockets user and manufacturer corporations exercise control and the actual creators of the software are supplicants.
- Governance is exclusively by individual software creators, as it always should have been with Open Source. Users have a voice, corporations can not dominate governance and exploit the developers.
- Effective enforcement: One entity is empowered to enforce on behalf of all developers, and is funded to do so. No more rampant license violations. Infringement or breach of contract results in loss of rights regarding the entire Post-Open software collection, not just one program.
- Strong anti-software-patent terms. Bring suit and you lose privileges regarding all software in the Post-Open software collection, not just one program.
We also have some non-goals:
- Don’t worry about when or if today’s giant companies will join Post Open. The answer to When will IBM come on board may well be never, because for such a large company, participation would mean a new USD$60 Million dollar per year fee (1% of USD$6 Billion). Instead, attract small and new companies with a free license, and grow them into paid license customers.
- Deep-pockets non-profits don’t get a free ride, just the same cheap one we give other deep-pockets entities. This is especially important in the field of science: non-profit research entities generally partner with for-profits that capitalize their research to great profit, and the entire field of software for science needs paid support and developer compensation. There are also non-profits that are of dubious public service, for example religious entities generally service their own communities exclusively, and have accumulated great wealth tax-free.
Progress So Far
So far, we have implemented part of the legal structure necessary to carry this out. There is a Post Open Zero-Cost License draft, and a Paid Contract draft. We have retained a law firm, pro-bono, to review these and give them some legal solidity, but they have only promised 20 hours of work. Many documents and processes are not yet developed.
Post Open will develop the Post Open Collection, a body of software that is licensed to users, through two processes: direct licensing of new work under the Post Open license, and dual-licensing of existing Open Source work as Post Open. Mr. Perens is well-informed of how to operate re-licensing of large-scale projects, having consulted on the re-licensing of Wikipedia. Dual licensing preserves the Open Source license of the software, and paid Post Open users will pay for the Open Source as well. This provides a revenue source for present Open Source projects.
Post Open will license the entire collection, not individual programs. It will use its own zero-cost license, a newly-developed license, for individuals and small businesses. They will receive the software for free, as happens today with Open Source. The zero-cost license addresses the known abuses and loopholes of Open Source licensing.
Entities which have annual revenue of greater than USD$5 Million per year, and those that wish to embed the Post Open software in a commercial product or make private modifications to the Post Open software must use the paid contract, which includes the zero-cost license by reference. The paid contract requires an annual compliance process, including
- Payment of 1% of revenue per year.
- A machine-readable accounting of what Post Open software the company uses, embeds in products, and performs as a service and the degree of use (for example, the count of products sold that contain the software).
Although the paid license gives the right to make private modifications, there are strong incentives for a company with the paid license to publish modifications. First, published modifications are maintained, and those that are not published must be manually ported to each new version of a program. Second, the developers of Post Open code get paid for their contributions, and a company that publishes enough Post Open modifications and new software will not have to pay for Post Open. If they publish more, we’ll pay them.
The compliance information and payment are submitted to a CPA (certified public accountant) that is contracted to the Post Open Administration, under NDA (non-disclosure agreement). The Post Open Administration does not see the customer’s software-use information or the information about their annual revenue, including the amount that they paid. That is kept to the CPA, which provides the Post Open Administration with totals and the received funds.
Software-as-a-service businesses must also submit the identity of customers for whom they perform software in the Post Open Collection. Both the SaaS vendor and the customer are subject to licensing.
Revenue collected by the Post Open administration will have a portion withheld for taxes and operational purposes, and the rest will be divided among the developers according to the popularity of their software and the size of their contribution. To understand a developer’s contribution to the Post Open Collection, we will instrument git repositories. There is presently a company, Merico, that has produced software for this purpose, or we can produce our own. We will take the totals from the software use reports by companies under the paid contract, and the portion of the software produced by each developer which we derive from the git repository, and arrive at amounts to be apportioned to developers.
There are also going to be project staff who can not be accounted for by lines in git repositories. The initial development of Post Open will only pay developers and creators of documentation by software usage and the size of their contribution. Payment for other roles will be developed later.
Post Open presently requires funds for its development, and will require external financial support for its first several years of operation, before it is able to self-support from licensing and service revenue. The compliance process is carried out after the end of a company’s fiscal year during which it participated in the paid contract, thus the first year of operation of Post Open is expected to produce little funding.
Post Open will develop a service organization that services all of the Post Open collection, rather than one program. Post Open will contract or employ first-line service staff who deal directly with the customer. We will pay the software developers to fix their own software, but insulate them from having to deal directly with the customer. Service revenue in excess of cost will be distributed to developers using the apportionment process.
Post Open will maintain the canonical download site for the Post Open Collection, operate its own git repository (possibly contracting an entity like github), and will positively identify all participating developers (so far, we like CLEAR, the airport expedited security folks who also sell positive identification of net users, but there are many services for doing this). We will provide developers with cryptographic passkey devices so that they are not subject to password attacks (these are available for as low as $14 at this writing), and maintain the chain-of-custody of software with each developer check-in, all of the way to the user, so that our software can be trusted and any bad actors can be traced and prosecuted. Files made available for download will be cryptographically signed, to further support integrity of the chain-of-custody. (We like the Nitrokey HSM device and the rest of their devices for operating our own cryptographic certification authority.)
A portion of revenue will be set aside for enforcement of the Post Open license and contract. The Post Open Operating Agreement will include authorization of the Post Open Administration to enforce on behalf of any developer of a work in the Post Open Collection, and breach leads to termination of rights on the entire collection, not just the program in question.
As Post Open collects revenue, it will develop representation of the developers for lobbying and other purposes. This is sorely needed because Linux Foundation represents corporations, not developers, and is one of the few Open Source organizations that can consistently afford to lobby.
There will be other ways that Post Open supports the developers, for example we may acquire advice for them on how to handle tax and legal complications associated with their revenue from Post Open.