Actually, just fortune will do. I was
once asked what my motivation was for going the open source route. I
know that it sounds shallow and selfish, but my motivation is simple -
Money. Like SAP, IBM, Microsoft and a few others, I want to make money. Lots of it!
Unlike the above companies though, I do not need it so bad that I have to make people bleed to get it, and secondly, my "Lots of money" is very different to theirs.
So how do I intend to get rich giving away the software?If you haven't read it yet, maybe you should read my plan for this software first. You will soon realise that there is plenty of work to be done. Far more than I could ever hope to achieve on my own. Coupled with that problem is the fact that I do not have the capital to back a development team. My best option is of course - Open Source. I need to make contact with the legions of developers out there that can help my cause. My next problem then becomes, how to get (and keep) first class developers interested in my project beyond a casual technical interest and into a large commercially viable product.
I have created a model for this project that will give the developers ownership in a way that I have never yet seen. Maybe it's out there, I just haven't seen it. I would like to test this model and hopefully, if successful could breathe life into many projects using the same method.
The ModelProbably the best way to explain my model is to use an example. Lets say that I have, to date, taken 500 hours of development time to develop what we will use from this point onward. I issue myself with 500 bassets (bassets? Of Course! blog is to web log as basset is to web asset). To make things interesting, I donate $100 to the project. So I now own 100% of $100. Each basset is valued at 20c
Now (to keep the maths easy), I manage to get one other developer interested in the project and he/she does a further 500 hours of development and I do no more. For each hour, another basset is issued to the developer. At the end, we each own 500 bassets, the fund is still valued at $100. Each basset is now valued at 10c. At any point in time the developer can cash in his bassets. This has the effect of reducing his ownership of the fund but does not change the basset value.
Now suppose a kind user donates another $100 to the project. The fund value is now $200 doubling the value of the basset back to 20c again. Further, an outsider buys a partnership agreement for $1800 (to aid the mathematically challenged) making the fund value $2000. The new basset value is $2.
As the project is now complete and the world can see what an amazing product C-Flow is, a corporate investor decides that the basset value is increasing at a rate and purchases 1000 bassets at the ruling value. The fund value is now $4000 and consists of 2000 bassets - still $2 each.
$1000 is used to fund some advertising and another two partnership agreements are sold at $1500 each (again for the sake of the maths). The fund value is now $6000 and the basset value - $3. The enlisted developer now decides to get out of the project and cashes in his/her bassets for a tidy $1500.
This method has some implications. Firstly, the value of the bassets could sit on zero for months during the initial phases of the development and may never actually attain a worthwhile value. This is a calculated risk on the part of the developer. Secondly, it is imperative that the model is controlled properly as the money holder could be on a beach in Hawaii if he has total control. Also a committee of some kind will need to oversee the allocation of money to advertising etc.
If you approach this project as a volunteer, when C-Flow pays out a dividend, it will be a nice bonus. I genuinely believe that there is a model out there that can help the open souce community in funding their projects and this model may, or may not, be the one that will work. It is however, a good start in the right direction and allows for developer ownership - not just volunteer work.
The number of hours allocated to a job or upgrade will be handled by an auction. For example, a bug is listed in the bug tracker. The developers check the bug out and place a bid on the developers auction. Developer 1 bids 2 hours work and developer 2 bids 3 hours work. The job is granted to developer 1 who takes 5 hours to complete the task. On submission of the completed code (and after testing), the developer is issued with 2 new shiny bassets. I really think this model has potential
C-Flow will be a framework for rapidly creating business applications. The applications can be easily developed by anybody with a pc, masses of technical brilliance and an acute business accumen and several degrees. Just kidding! It is nonetheless, a programming language and will require the expertise of a programmer. A C-Flow application will typically be setup by different people from the users. Now these people that set up the application may be the IT department (ie internal to the organisation) or consultants (external).
In the case where the product is developed internally, the application is developed and 'added to' in the normal "manage by emergency" business process of all IT departments then the product is free in the usual way. However, when an application developer decides that he/she would like to develop a module and prevent others from looking at his code by locking the product, then a locking key (or developers licence) will be charged for. Of course, project team will never be expected to pay for locking keys. (or maybe they should, it will help in funding - these things can be discussed later.)
Developer license fees, donations and partner program fees, should all be distributed amongst the team and rightly so. This model is a good method of carrying out this distribution in a fair and unbiased manner.
Also, I believe that if there is a better way out there to give developers ownership, then obviously, the highly intelligent members of this team will come up with the answer. This will be the elite, the A-Team, the Top Flight.