Business Models and Best Practices Best Practices I) Company Organisation Managing external contribution vs pay...Managing external contribution vs payment in cash
Usually the ratio of open source contributors to complaining onlookers decreases as project size increases. We found that, generally speaking, a healthy open source project has:
- a core team with a few (1-5) project leaders
- about 10x as many code contributors as leaders
- about 10x as many contributors (mailing list discussants and bug reporters) as code contributors
- about 10x as many lurkers as contributors
- about 10x as many users (people who download the product) as lurkers
- about 10x as many visitors to the site as actual users
The interesting thing with a sustainable software license is that this paradigm tries to push the "pyramid of participation" towards the top and to accelerate promotion in the hierarchy by enforcing a "contribute or pay" paradigm. Customers have now no choice. They HAVE to make something else they will be taxed (= payment of their license fee in cash). This is what we call the "UnValue Added Tax" mechanism. If you do not want to involve yourself in the community, other members will require a tax to compensate your lack of work.
Thanks to this mechanism your development community is created more rapidly than for other open source projects. However the problem is that it is often more interesting for a customer to ask for a payment in kind rather than a payment in cash especially while outsourcing some developments to an official "R&D Lab" for a fixed fee. Indeed your customers can now face two choices:
- Buy 1 license in cash
- Get 1 free license AND get one new additional feature for the same amount.
Of course, everybody will then try to choose the second option if they have such a choice.
Best Practice:
Clearly put in place a fair balance solution between the risks and advantages of a payment in cash or in kind. Each type of payment should give different privileges and responsibilities. Payment in kind should not be an easy way to get some free or discounted license. Accepting to pay in kind for a customer also means that he has to assume the development risks related to his planned new feature.
Comments:
This is one of the most difficult part to manage with a sustainable software project. Customers will always require new additional features if, for a similar price, they can benefit in the same time of all the advantages in terms of software license without assuming more risks or responsibilities.
We then recommend letting the customer assume the whole risks of developing a new feature. The customer should keep the overall responsibility of the new feature even if he delegates to your R&D Lab or to another system integrator the development of the code. Ideally your R&D lab should not accept any fixed fee payment in exchange of a contribution in kind. In such a case you will assume all the financial risks even if the development planned is finally more complex than initially thought AND, in opposite to a traditional software vendor, you will not be able any more to decide of the development priority for your software.
So one of the best practices would be to clearly divide:
Process 1: payment in cash - you act as an editor
The license fee allows you to finance a dedicated R&D team. YOU choose your development planning and milestones, the key features you want to add and their scope, your software long term vision,... in exchange YOU assume the development risks (delay, complexity, recruitment...).
Another option to better balance the payment in cash option for your customer is to propose some better level of support or assistance compared to a contributor in kind.
Process 2: payment in kind - you act as an IT integrator or a CVS Committer
The customer decides of the newly wanted feature. He determines the functional needs, the scope, the future GUI,... so HE has to take in charge the user requirements and/or the development. Of course he can assign his own internal developers and decide to assume all the development risks himself. In such a case you will not have a lot of problem excepting valuing his contribution (see next best practice). But if he decides to outsource the developments to your "R&D Lab" or to another system integrator, you will have to really be careful that HE continues to assume at least all the financial risks related to the development of his new wanted feature. You do not have to assume all the risks related to developing a new functional feature while in the same time providing to him free licenses.
Some other solutions you may apply are:
A) Create a "committer tax"
Create a cash-only "tax" to finance additional work required to integrate, test, document, bug fixes the customer new enhancements provided by a payment in kind.
Usually the R&D lab(s) is(are) in charge of managing the main CVS (write accesses on the main CVS). So they will always have a certain level of work in order to coach, assist, train or help other developers in the community (read only access). They will also have to finally integrate, test, debug, document and perhaps even develop new migration scripts in order to fully integrate the new suggested enhancements in the core program. All these tasks should be compensated from a certain manner. You can then decide that standard "developers" in the community will have to pay a percentage of the license value paid in kind to one of the official "committer" in the main CVS (e.g. 10% of the total license value). This "committer tax" can of course be deducted from the value of the customer license fee. Of course any "developer" in the hierarchy may become one day a "committer" according to his level of expertise and to his contributions to the project. This hierarchy of roles and responsibilities is then 100% similar to other open source projects excepted that CVS Committers could be financially rewarded for the extra tasks they are doing.
B) Fix the license conversion rates
Usually the conversion rate is floating according to each customer project, to the integrator in charge of developing it, to the country where it was developed, etc... Moreover usually the rate applied for the conversion is the billing rate of the system integrator in charge of developing the functional enhancement. But which rate will you then apply for developers directly recruited by the customer (their internal hourly rate)? Why should you accept a different conversion rate for a similar contribution according to the customer that suggests it?
Finally another criteria to consider is that you, as an editor, will have the choice of either developing such a functional enhancement with your own resource or either letting a third party partner or customer develop it. As the cost of your internal developer is not equal to the billing cost of your partner, this means that you may certainly develop the same feature for a lower cost internally. Of course, this is similar to outsourcing some of your internal development to an external IT company and you will have to accept an higher rate than your internal hourly cost.
But for all these reasons, you may decide to fix the conversion rates (for example per level of skills and experiences).
This last solution is quite difficult to implement in practice as you will often work with third party partners (system integrators, web agencies,...) that will not agree to disclose and to explain to their customers why they will have to manage two different values for their development (= the development budget billed by the partner and the license conversion budget calculated with the editor fixed rate).
Sustainable Software is right in the middle between classical commercial proprietary product (with support, pre-sales,...full time dedicated teams) and open source software (delivered as-is, do it yourself attitude = "it will be ready when it will be ready, if you are not happy with it, please contribute"). This means that you will be often facing the following remarks: "You are the editor, please give me some release deadlines, some code warranties,..." or: "We have found a bug, could you correct it ASAP" while in the same time this same customer will try to pay his license fee in kind.
That is why we strongly recommend to clearly balance the risks and responsibilities for each process. You do not have to play a software editor role if the customer is paying in kind.
- a core team with a few (1-5) project leaders
- about 10x as many code contributors as leaders
- about 10x as many contributors (mailing list discussants and bug reporters) as code contributors
- about 10x as many lurkers as contributors
- about 10x as many users (people who download the product) as lurkers
- about 10x as many visitors to the site as actual users
The interesting thing with a sustainable software license is that this paradigm tries to push the "pyramid of participation" towards the top and to accelerate promotion in the hierarchy by enforcing a "contribute or pay" paradigm. Customers have now no choice. They HAVE to make something else they will be taxed (= payment of their license fee in cash). This is what we call the "UnValue Added Tax" mechanism. If you do not want to involve yourself in the community, other members will require a tax to compensate your lack of work.
Thanks to this mechanism your development community is created more rapidly than for other open source projects. However the problem is that it is often more interesting for a customer to ask for a payment in kind rather than a payment in cash especially while outsourcing some developments to an official "R&D Lab" for a fixed fee. Indeed your customers can now face two choices:
- Buy 1 license in cash
- Get 1 free license AND get one new additional feature for the same amount.
Of course, everybody will then try to choose the second option if they have such a choice.
Best Practice:
Clearly put in place a fair balance solution between the risks and advantages of a payment in cash or in kind. Each type of payment should give different privileges and responsibilities. Payment in kind should not be an easy way to get some free or discounted license. Accepting to pay in kind for a customer also means that he has to assume the development risks related to his planned new feature.
Comments:
This is one of the most difficult part to manage with a sustainable software project. Customers will always require new additional features if, for a similar price, they can benefit in the same time of all the advantages in terms of software license without assuming more risks or responsibilities.
We then recommend letting the customer assume the whole risks of developing a new feature. The customer should keep the overall responsibility of the new feature even if he delegates to your R&D Lab or to another system integrator the development of the code. Ideally your R&D lab should not accept any fixed fee payment in exchange of a contribution in kind. In such a case you will assume all the financial risks even if the development planned is finally more complex than initially thought AND, in opposite to a traditional software vendor, you will not be able any more to decide of the development priority for your software.
So one of the best practices would be to clearly divide:
Process 1: payment in cash - you act as an editor
The license fee allows you to finance a dedicated R&D team. YOU choose your development planning and milestones, the key features you want to add and their scope, your software long term vision,... in exchange YOU assume the development risks (delay, complexity, recruitment...).
Another option to better balance the payment in cash option for your customer is to propose some better level of support or assistance compared to a contributor in kind.
Process 2: payment in kind - you act as an IT integrator or a CVS Committer
The customer decides of the newly wanted feature. He determines the functional needs, the scope, the future GUI,... so HE has to take in charge the user requirements and/or the development. Of course he can assign his own internal developers and decide to assume all the development risks himself. In such a case you will not have a lot of problem excepting valuing his contribution (see next best practice). But if he decides to outsource the developments to your "R&D Lab" or to another system integrator, you will have to really be careful that HE continues to assume at least all the financial risks related to the development of his new wanted feature. You do not have to assume all the risks related to developing a new functional feature while in the same time providing to him free licenses.
Some other solutions you may apply are:
A) Create a "committer tax"
Create a cash-only "tax" to finance additional work required to integrate, test, document, bug fixes the customer new enhancements provided by a payment in kind.
Usually the R&D lab(s) is(are) in charge of managing the main CVS (write accesses on the main CVS). So they will always have a certain level of work in order to coach, assist, train or help other developers in the community (read only access). They will also have to finally integrate, test, debug, document and perhaps even develop new migration scripts in order to fully integrate the new suggested enhancements in the core program. All these tasks should be compensated from a certain manner. You can then decide that standard "developers" in the community will have to pay a percentage of the license value paid in kind to one of the official "committer" in the main CVS (e.g. 10% of the total license value). This "committer tax" can of course be deducted from the value of the customer license fee. Of course any "developer" in the hierarchy may become one day a "committer" according to his level of expertise and to his contributions to the project. This hierarchy of roles and responsibilities is then 100% similar to other open source projects excepted that CVS Committers could be financially rewarded for the extra tasks they are doing.
B) Fix the license conversion rates
Usually the conversion rate is floating according to each customer project, to the integrator in charge of developing it, to the country where it was developed, etc... Moreover usually the rate applied for the conversion is the billing rate of the system integrator in charge of developing the functional enhancement. But which rate will you then apply for developers directly recruited by the customer (their internal hourly rate)? Why should you accept a different conversion rate for a similar contribution according to the customer that suggests it?
Finally another criteria to consider is that you, as an editor, will have the choice of either developing such a functional enhancement with your own resource or either letting a third party partner or customer develop it. As the cost of your internal developer is not equal to the billing cost of your partner, this means that you may certainly develop the same feature for a lower cost internally. Of course, this is similar to outsourcing some of your internal development to an external IT company and you will have to accept an higher rate than your internal hourly cost.
But for all these reasons, you may decide to fix the conversion rates (for example per level of skills and experiences).
This last solution is quite difficult to implement in practice as you will often work with third party partners (system integrators, web agencies,...) that will not agree to disclose and to explain to their customers why they will have to manage two different values for their development (= the development budget billed by the partner and the license conversion budget calculated with the editor fixed rate).
Sustainable Software is right in the middle between classical commercial proprietary product (with support, pre-sales,...full time dedicated teams) and open source software (delivered as-is, do it yourself attitude = "it will be ready when it will be ready, if you are not happy with it, please contribute"). This means that you will be often facing the following remarks: "You are the editor, please give me some release deadlines, some code warranties,..." or: "We have found a bug, could you correct it ASAP" while in the same time this same customer will try to pay his license fee in kind.
That is why we strongly recommend to clearly balance the risks and responsibilities for each process. You do not have to play a software editor role if the customer is paying in kind.
The contents of this website are licensed under the Open Software License 2.0 or Academic Free License 2.0
 Top |
 |
