OpenSource 3.0 - A Long Term Business Model for Software Development

This document represents an idea about how OpenSource-projects could change the business models of software development to a more sustainable direction. Donation based OpenSource-projects already exist, Wikipedia being the one every one of you knows.

With some clever software tinkering, we could enable this business model to everyone who operates within the scope of OpenSource; building OpenSource-solutions, building software solutions based on OpenSource-solutions and in general people who consume, maintain, design or do business with OpenSource-platforms.

The idea of this is to get ideas how this could become reality: this is such a good idea, that someone has probably already made all the APIs I need for this to happen. If you seem to know more about what I am trying to do, please share! This is iterative process (life is an iterative process) and I will improve this every day. Give me feedback!

## OpenSource Sponsorship Program

Today software is built upon OpenSource solutions, you pretty much never start from the scratch. Common platforms are building upon something someone else has already built (this blog is might be based on Linux, PHP and MediaWiki, all OpenSource projects consumed by billions of users every day for free).

When you buy a software solution from a company it is always built with OpenSource components. This is good. But most of the time the software company bills at least 80€ an hour (or they are doing bad business) but gives nothing back to OpenSource company, or at least it is voluntary effort, often not encouraged by the employer (you have to either do the contribution at your spare time or risk customer relationship or your job in order to contribute). This is BAD!

But I can't blame anyone. Everyone is just doing their own business, the customer pays for software solutions and the software company delivers software solutions. Every time I am pushed to "just do the solution" instead of building a reusable OpenSource solution, I get kind of frustrated feeling, but no one is paying me for doing the OpenSource rolution, so I kind of accept it.

Because of this frustration, I came up with this idea:

* Let's build a place where customers can register their domains (e.g. http://wikia.com) and share their package management lists (e.g. composer.json files from their version control) and sponsor OpenSource community with any amount of money they want (donation)
* The OpenSource packages will have their own bank accounts
* The sponsorship money is divided evenly between all the packages used by the customer
* Each OpenSource package will earn 40% and 60% is divided evenly for all the packages / repositories (we need a fair formula for this) used by the package (MediaWiki uses PHP)
* The owner of the OpenSource package will decide what they will do with the money

For example, if I would sponsor this blog with 50€ a month, then "MediaWiki" would get 20€, PHP would get 12€ and whatever PHP is built upon would get 18€ to share.

Technically this would be very easy to do; in PHP world many projects are at GitHub (which could have the bank account information of the repository owners), we have Packagist and Composer to resolve the dependecies of the packages... and that's all we need to know!

## Why this might be a terrible idea?

**OpenSource is supposed to be free!** However, because **this is a sponsorship program** all OpenSource programs will remain free. Supporting OpenSource would be ethical choice done either by the customers (direct payments) or the software company (paying voluntarily X% of their monthly revenues back to the OpenSource community per customer). I don't believe in a world where a software company bills 20,000€ a month and would not be willing to share less than 200€ a month back to community. The community, which has made it's entire business model profitable. It's 1%! If you disagree, go shoot yourself, sir.

**People who own the repositories would become greedy!** No they won't. So far they have done all this for "free". Of course they can somehow monetize the ecosystems they've built (selling expert consultancy, tech support, licenced advanced features, training etc.); they have already built succesful careers upon something that is free to use. Of course there is the myth of OpenSource developers who code for free in order to save the world. Let me tell you something, the same myth is everywhere as an excuse: every best-seller is written by urban hermits who love alcohol more than the company of other people, every rockstar has a drug addiction, every successful person has something inherently bad empowering them to be good.

This is not true. True OpenSource developers believe in network effects and build careers upon it. In my first start-up (tried to build music industry event booking system with augmented crowdintelligence for decision making support) I hired this Swedish guy, who had already a music industry **career of three decades** behind him! I asked him how he did it, and his answer was brilliant:

"I do other people favors. I never use the favors for myself. When I know someone who need a favor, I will arrange a meeting with someone who is best possible person to make it it happen. When they do successful business together, I have two people willing to return a favor for me. And then I will arrange a meeting, when someone needs a favor from them."

He is not a rich guy (as far as I know), but I envy him. He loves what he does, he travels a lot, knows everyone from the industry and is a VIP for every gig at any town he might currently be located. When you measure him with money, he is not rich, but when you measure him by the dreams every young music industry entrepreneur wants to achieve (I used to be that guy), he is more rich than many musicians playing in the biggest bands today. He is not greed, he shares, makes things happen and loves what he does. AND has a successful career.

**Software companies will start doing bad business!** Well... that's their problem. If they will invest for OpenSource development in hopes for long term profits, but fail, they are not good enough in what they do. Some software companies are parasites, just like the medschools in USA of early 20th century. It was the early days of healthcare, surgeons had huge salaries and everyone wanted to become a surgeon. Well not everyone. Some realized that one thing more profitable than becoming a surgeon is the business of educating surgeons!

You could become a surgeon by attending to class room lessons for three years. First few patients died on the table. Albert Flexner thought that this is not okay and with the aid of the government 70% of all medschools were closed and the rest were merged with popular universities and forced for more scientific and pragmatic approaches to educate surgeons that actually can do their job without anyone getting killed.

Software industry is young, especially Web-application industry. Some of us kill our customers with expensive projects for short-term profits. My idea of OpenSource 3.0 / sponsorship will reward successful software developers with a mechanism of long-term profits from OpenSource contributions. When the long-term profits from OpenSource contributions start to grow, the software company can dedicate more developers to build more OpenSource instead of in-house customer projects (which are not based on the values of sharing).

## Okay, what next? How can I be part of this?

Spread this idea, in the spirit of OpenSource. I don't like the idea of ownership of ideas, I like the idea of sharing.

You could contribute to improving this document and idea by adding comments or contacting me at LinkedIn or Facebook

I also made a GitHub repository for this project, so you can follow my progress with this idea.

Of course I could do this on my own and become a millionaire by charging a 0.001% provision from OpenSource sponsorships (there are quite many software projects in the world...), but I don't believe in the philosophy of doing things on my own... I actually hate nothing more than doing things on my own.

I just want this idea to become reality, so here is a list of things you can do:

* Make a feature request to GitHub, BitBucket etc. (this list is too short, write me a comment about similar web-sites and I will add them), where Organizations (customer repositories) can donate on monthly basis and other Organizations (OpenSource-projects) can add a bank-account, PayPal-account or whatever to receive payments. The MVP of this idea could just allow customer (the developer maintaining the repository) to fill in the dependencies; later there could be a dedicated package management files (composer.json, packages.json), which would be automatically updated.
* Another ecosystem which could implement this idea, is the package managers themselves (Composer, Node etc.).
* There might be some other ways to do the payments... there might be easy billing API, so all we need is a software system, let's call it OpenSource3.0:
	+ Where software companies can store the Web URI's of their customer sites
	+ The customer sites would expose composer.json etc. files publicly... I am not sure if there would be security risks if the used versions are exposed, so maybe just expose only the libraries used with some kind of parser
	+ The package management software is used to track the repository URI
	+ Then OpenSource3.0 will read the file, which contains the payment methods accepted (this could also be extension of humans.txt):
		- It might be a nice idea to add "legacy" contact information, so that you could just say Hi! and thank people for job well done, some times this kind of encouragement is enough for someone to code for free
		- But in the end we want some nice "pay here" API
		- Because there might be some legal issues of collecting the sponsorship money, BitCoin might be a good government independent solution: the company paying the sponsorship will treat the sponsorship as a licence fee in their accounting and the receiving end will treat the sponshorship as a licence payment.
		- I am evaluating these alternatives for payment. It seems like the most interesting candidates seem to be the API of Stripe and Dwolla.

**Status of the documentation 16:00 14.3:** I have slightly improved the specification and spread the word out, but now I have to cook some food for me and the girlfriendish person. See you later!

**Status of the documentation 13:00 14.3:** I will write a better specification later, now my girl friendish person is waiting for me to check bus schedules so that I could share a dinner with her. If you want to participate, contact me at LinkedIn or Facebook and provide me your GitHub account, so I can add you to the OpenSource3.0 project. Let's make this happen!

## Steal This Startup Idea! "OpenHub" a competitor for GitHub, BitBucket etc.

Let's copy GitHub or BitBucket as it is and add **"Donate to Developers" feature**:

* Each Organization can set their redistribution rate (**OpenSourceTax**); when they get donation, they will keep X% of the money and Y% of the money is redistributed evenly to the OpenSource-packages used by the Organization
* **Random note: It will work very similarly to Value Added Tax,** which everyone can set for their own Organizations
* The redistribution is an automated process. The Organizations Repositories will define where their package management files are (e.g. composer.json, packages.json) and the redistribution path (**Donation Path**) is crawled to the root.
* If a repository on that path is member of OpenHub, they will get paid and they will redistribute the set rate forward to "more popular repositories" upon which they had built their software.
* If Donation Path ends to a repository which has defined OpenSourceTax less than 100%, the OpenHub will keep the redistributed money and improve the service with that money.

Then we will build **OpenSource-certificate**, this is not that important feature, but easy to do and for some people this might have some value:

* It will be attached to a web-site owned by the Organization owner. A JavaScript component is added to the web-site, which will check the OpenHub API for Certification Level of the organization.
* The Certification Level is dynamic classification of how much the organization donates / developer. There will be different certificates for different kind of Organizations: Companies doing business upon OpenSource-platforms, Software Companies who customize OpenSource-solutions to businesses and OpenSource-companies.
* The Certification Level changes every month: top 10% will get Gold Certificate, top 40% will get Silver Certificate and top 70% will get Bronze Certificate. This will work as a reputation network within the OpenSource community.
* OpenSource-companies will have another Certificate, which will have levels based on how much money they receive from their community of users (Organizations that use their packages). Top projects are evaluated on how much they share and how much they receive.

Now that we have created an incentive for companies to share which OpenSource-projects they use and approximately how much they make money with them (assuming people will donate something like 1% of their revenue back to the community), we have established reputation network of OpenSource-projects:

* We will then establish new way of finding good components to use in your own projects
* When you upload the package dependencies OpenHub will start evaluating what kind of project you are building
* You can also add tags "similar to this project", "ecommerce", "CMS" and whatever you might come up with.
* Then you can browse the projects in a Netflix style view, where projects are categorized by the tags
* The projects are categorized by augmented intelligence basde recommendation system (similar to Netflix) to make navigation of the project suggestions easier. Of course you can use traditional ways to find new projects, but this would be just an additional feature for discovering projects you didn't know.
* For developers this recommendation system will be used to make it easier to find new technologies to evaluate. The OpenHub will analyze in which projects you participate and augment your learning by suggesting what to learn next.
* Then you can rate the technologies you have learned, which will further improve the recommendations for your personal tastes.

If you think this is the way of future software development, want to make this happen or know who could fund this kind of idea, contact me at at LinkedIn or Facebook. I will help you for free, because that is what I do. If you can provide me a joint venture, even better!

## OpenSource 3.0 for dummies (a sex metaphor, this has not been updated yet!)

Because they say, that the oldest business is whoring and Einstein said "You should be able to explain something to a six year old, or you don't know it well enough", I will use sex as a metaphor for OpenSource 3.0**business model.**This metaphor is quite misogynist, but I am drunk and it's friday, so bare with me (I am sorry!).

At the tribal age of mankind chicks had something guys appreciated, the means of reproduction (a way to digitalize your business). The dominant theory was the survival of the fittest for many years (most competent corporation of software subcontraction), but due to the collateral damage of the competition (**it's expensive not to share the risks of building new things**), altruism and cooperation emerged (OpenSource); you don't need to be another alpha male to get laid, you can fool the old fool with your friends to get laid, if they understand your goals (OpenSource community).

At the dawn of the civilization things got more complicated; in a city environment women could get raped (someone could steal your source code!), they could cheat on you (someone could make better business with your source code) etc. and the one who committed the crime would never get caught... unless there was some established laws and justice. Well... two things happened, marriages (software companies building closed-community solutions) and pimps (**OpenSource package managers**).

For a business, marriage is a bad situation, because you can't get laid with other people (vendor lock, not able to use the best solution in the markets) and you pay full price for it. Pimps are also bad, because you never know what kind of sexually transmitted diseases you get (bugs, dependency problems and the general problem of maintaining versions) and when you get affectionate relationship with a hooker (single OpenSource contributor), it might happen that one day that hooker might work for another pimp (for some reason the contributor has found something more important to do with life than coding for free).

If you have ever been in a relationship (worked for a big corporation), and then been cheated upon (coded with someone outside of the corporation), you know the itch, when your partner does things differently and it suddenly feels exiting and new (clever -- usually OpenSource -- soltions that save development time), even though you kind of know you have been cheated upon (used non-corporate soltuion). Good ideas are made to be shared (OpenSource), because there is quite a limited amount of innovation two entities can come up with (business partners can't think outside of the box, they are the box). When building serious relationships (B2B and B2G business models), that require commitment for future generations, marriage is a good solution. But when you are looking for better experiences (better software), but unwilling to commit to anything, many partners is a good solution (package management). The best solution is to combine both worlds, being committed to one project and sharing the information about avoiding the common problems (building upon OpenSource community as much as possible).

Maybe we should bring up software as communities? It doesn't matter who ever laid with whoever, we have kids (software projects) and they deserve better future than we do (cost-effective progress)? If you appreciate someone for what they give to you, you should reward them and give everything you have to help them through life. Or at least as much as you can share...