Post-Open: What Comes After Open Source

Post-Open is a new paradigm designed to address the present problems of Open Source, which have become obvious to everyone. The goals are:

  • Open Source will go on as it is today. Post-Open will never call itself Open Source, but you can dual-license Open Source and Post-Open and start getting paid. Users who join the paid license (to get the rights to exclusively Post-Open licensed software) also pay for dual-licensed Open Source.
  • Preserve software freedom for individuals and small business, the folks we really should be helping, rather than the richest corporations in the world. Provide individuals and small business the right to use, redistribute, and modify, and to get paid for their modifications!; publish all source code.
  • Require payment from deep-pockets entities (over USD$5 Million end-user revenue in a year), companies that include the software in a paid-for product, and companies that wish to keep modifications private.
  • Compliance simplicity: once a year, paid users account for their software use and end-user revenue, and pay a small portion (we’re considering 1%) of it for all Post-Open software, not just one program. Then compliance is over until next year.
  • Licensing simplicity: One zero-cost license, one paid license 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 checks that companies write 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, end-user 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. Apportion payment to developers based on software use and the size of their contribution.
  • Improve security and quality by reliably identifying developers, providing proper funding for developers to maintain their software, provide cryptographic-hardware-backed authentication and 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.
  • 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 corporations exercise control and the actual creators of the software are often unfunded.
  • Governance is exclusively by individual software creators, the way it always should have been. 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 violation. 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.

This presents significant challenges:

  • This is all a lot more complicated than Open Source, and requires funding for legal and process work that we don’t yet have.
  • To work, this needs lots of developers. Fortunately, it’s easy for existing Open Source developers to dual-license Post-Open, and getting paid is a strong incentive to do so.
  • It will be slow to accumulate paid users. Long-term, their expenses will probably be lower than today. Open Source Compliance departments at large companies can cost USD$7M/year, and security of unmaintained Open Source is becoming a serious threat.
  • Post-Open requires a central entity that receives and apportions payment, does enforcement, and operates the service entity (or three central entities, one for each purpose). Open Source developers are very independent, and have not had to deal with a central entity until now, even one that they own.
  • The apportionment process is complicated and not completely developed. It measures deltas to git repositories, and may require time accounting from people whose work can not be measured by lines of code. There may be issues with it being gamed, etc.
  • There’s an operating agreement to make this all work, and it requires some responsibility of the developer. Open Source developers don’t even like contributor license agreements, this will be an additional challenge.
  • Developer identification is necessary for the security mechanism. Sorry, no anonymity.
  • Governance that all developers can trust will be a severe issue.
  • The processes and legal documents are still under development.

Documents and processes are being developed, but have not been through legal review. Today, these exist:

Post-Open is being developed by Bruce Perens (the creator of the Open Source Definition, the rules for Open Source which have stood for 26 years) and public participants. To contact Bruce, email bruce at perens dot com.

Scroll to Top