Business Models and Best Practices Best Practices II) Software and License Management Valuing contributions in kindValuing contributions in kind
Accepting payment in kind means that you will have to determine the value of a suggested contribution. Such an exercise is of course not obvious and can be done from several different manners.
From experience, try to keep it as simple as possible. The goal is not to determine the exact value of a contribution to the exact cent. The main goal is to leave a choice to the users: either they contribute to the community, or they pay. Only the second criteria shall be related to the fact that the suggested enhancements should be approximately equal to the amount of license you will provide.
So do not take it as an exact science. This is more related to barter in a Moroccan market. No fixed price but if everybody is happy with the deal at the end this should be ok for all the actors.
Finally people are used to have low-cost "open source" software. They do not realize that developing a line of code for an open source program is no more, no less complex and costly than for proprietary software. So, when sponsorizing a new feature (= mandating one of the existing developer in the community), they are sometimes "surprised" to see the value of the work. The fact that you are working on an open source or sustainable software shall never be a reason to reduce a development budget.
Best Practices:
Contributing in kind must not be an easy way to get rid of a license payment in cash. Keep valuing methods as simple as possible.
Comments:
You have several ways to determine the value of a software contribution. This is not something easy. Most of the time you will have to try to make a valuation based on a Time = Money paradigm. Of course a junior developer should not be "billed" at the same rate as a senior software architect. You will also have to deal with the complexity of the suggested development (implementing a new GUI is often not as complex as modifying the core kernel) or with the market value of the suggested development (implementing a nice to have feature is not the same as developing a new urgent "market killer" enhancement).
Moreover while using some development man/days rating or similar benchmark used in the IT industry, you will also face the globalisation issue. What if the customer is located in a country where the cost of life (and salaries) is significantly lower. Does it mean that he will have to work more than a American or European contributor in order to finance his license? That is why we recommend to use some standard development rate valid for all developers wherever they are located.
Another thing to consider is the process you will put in place and the level of involvement you will have during the development of the contributions (specification review, code review, final acceptance,...).
Firstly you will have to determine early in the process if the proposed contribution is in line with your vision of the program. Take care not not to allow contributors to work on some contributions without your prior consent that will suddenly require some license compensation to you. You (or the Technical Committee) will have to decide at first if you want such an extension or not and if it is in line with your technical vision. Do not forget that you have the right to refuse a suggested contribution.
You will also get into trouble if several "hidden" undeclared contributors are trying simultaneously to develop the same new enhancement. In the end, you will certainly not accept to "pay" several times the same features...
Secondly only accept generic and reusable code. Do not accept any specific custom code as a contribution in kind. This is pure integration work and has nothing to do with software development. Every contribution in kind should bring a clear added value to the whole community (or at least a large part of it).
Finally there is often some development time required between the acquisition of the license and the contribution of code itself. This means that, similar to any system integrator answering to a quote, your customer will have to value their suggested development before doing the work. As mentioned in "Managing external contribution vs payment in cash" this is not the role of the editor to assume the development risks related to implementing a new enhancement.
P.S: What if the value of the contribution exceed the value of the customer needed license?
You then have two possible choices:
1) The customer agrees to "value" his contribution at a lower rate.
2) You provide a credit on future possible license acquisition.
From experience, try to keep it as simple as possible. The goal is not to determine the exact value of a contribution to the exact cent. The main goal is to leave a choice to the users: either they contribute to the community, or they pay. Only the second criteria shall be related to the fact that the suggested enhancements should be approximately equal to the amount of license you will provide.
So do not take it as an exact science. This is more related to barter in a Moroccan market. No fixed price but if everybody is happy with the deal at the end this should be ok for all the actors.
Finally people are used to have low-cost "open source" software. They do not realize that developing a line of code for an open source program is no more, no less complex and costly than for proprietary software. So, when sponsorizing a new feature (= mandating one of the existing developer in the community), they are sometimes "surprised" to see the value of the work. The fact that you are working on an open source or sustainable software shall never be a reason to reduce a development budget.
Best Practices:
Contributing in kind must not be an easy way to get rid of a license payment in cash. Keep valuing methods as simple as possible.
Comments:
You have several ways to determine the value of a software contribution. This is not something easy. Most of the time you will have to try to make a valuation based on a Time = Money paradigm. Of course a junior developer should not be "billed" at the same rate as a senior software architect. You will also have to deal with the complexity of the suggested development (implementing a new GUI is often not as complex as modifying the core kernel) or with the market value of the suggested development (implementing a nice to have feature is not the same as developing a new urgent "market killer" enhancement).
Moreover while using some development man/days rating or similar benchmark used in the IT industry, you will also face the globalisation issue. What if the customer is located in a country where the cost of life (and salaries) is significantly lower. Does it mean that he will have to work more than a American or European contributor in order to finance his license? That is why we recommend to use some standard development rate valid for all developers wherever they are located.
Another thing to consider is the process you will put in place and the level of involvement you will have during the development of the contributions (specification review, code review, final acceptance,...).
Firstly you will have to determine early in the process if the proposed contribution is in line with your vision of the program. Take care not not to allow contributors to work on some contributions without your prior consent that will suddenly require some license compensation to you. You (or the Technical Committee) will have to decide at first if you want such an extension or not and if it is in line with your technical vision. Do not forget that you have the right to refuse a suggested contribution.
You will also get into trouble if several "hidden" undeclared contributors are trying simultaneously to develop the same new enhancement. In the end, you will certainly not accept to "pay" several times the same features...
Secondly only accept generic and reusable code. Do not accept any specific custom code as a contribution in kind. This is pure integration work and has nothing to do with software development. Every contribution in kind should bring a clear added value to the whole community (or at least a large part of it).
Finally there is often some development time required between the acquisition of the license and the contribution of code itself. This means that, similar to any system integrator answering to a quote, your customer will have to value their suggested development before doing the work. As mentioned in "Managing external contribution vs payment in cash" this is not the role of the editor to assume the development risks related to implementing a new enhancement.
P.S: What if the value of the contribution exceed the value of the customer needed license?
You then have two possible choices:
1) The customer agrees to "value" his contribution at a lower rate.
2) You provide a credit on future possible license acquisition.
The contents of this website are licensed under the Open Software License 2.0 or Academic Free License 2.0
 Top |
 |
