Business Models and Best Practices Best Practices I) Company Organisation Allocating software revenuesAllocating software revenues
Sustainable Software allows the editor to charge a royalty on certain type of program execution (not for test or development purpose but for internal or commercial use). This means that, in opposition to classical open source projects you will be able to manage some direct license revenue streams. However, in opposition to proprietary software, the user of the technology will be also able to pay his license fee in kind.
Concretely speaking this means that certain users will pay in cash and others in lines of code. If a customer chooses the second option, he will have two main ways of contributing to the project:
1) He has some internal development resources he can assign on the project in order to develop some functional and value added enhancements.
2) He outsources the development to an external IT company (= what we call sponsorising the development of a new feature). These external IT companies are most of the time the "R&D lab(s)" that regroup(s) the key architects and developers of the technology as they often have the best technical knowledge on the code base but this may also be any system integrators that has some technical knowledge on your program.
This means that, from a consolidated perspective if you separated your product and services structure (cf. previous best practice), your revenues streams will be split between software license and development services contracts.
Of course, your "R&D Lab" may also be directly "mandated" by the product company on a long term basis in order to maintain the product, to take in charge the coordination of the community, to support the free mailing lists or to develop some major new features. This is one of the possible way to assign license revenues paid in cash to a team of dedicated full time developers in charge of managing the product on a daily basis.
Best Practice:
Assign the license revenues to software maintenance or to major code refactoring. Let the customers drive the software minor releases by accepting payment in kind.
Comments:
A software development job is NOT an integration job. Software development shall be analyzed and developed on a long term perspective from a generic manner. Services contracts are often short term focused and specific to each customer's project.
In practice this means that customers are usually not really interested in maintaining the code base (testing new drivers, updating internal libraries, optimizing the code...), in documenting the software or in refactoring the core kernel (major release cycle).
However, most of the time they will be immediately interested by adding some small new features or modules that could immediately bring to them certain functional enhancements.
The software editor will then have to take care to recruit and finance a dedicated, experienced, long term driven team of core developers that will be in charge of the tasks that the "community" does not really want to do. Thanks to cash revenues this is possible and this mechanism brings a real value added to the sustainable software approach. Customers know that there is a dedicated team of developers that will envision the future of the software, coordinate the community and maintain the existing code base. This is often a real security for customers to know that there is a "real" editor behind the software and not just some key developers that can vanish from one day to the others. They can now also focus their time on adding the new functional enhancements they needed for their internal project, something that their management may also more easily approve in terms of budgets or resources.
Key points to finance through license paid in cash
- Major kernel refactoring / major releases - The total cost of such a sub-project is often too high for one single customer. Sharing such a cost among several customers could be the best practice but is practically always tricky to realize and to coordinate as all the customers do not have the same needs, projects and budgets available in the same time.
- Community coordination and support: This will be up to the dedicated R&D team to coordinate all the actions of the community in order to be able to manage the software release cycle. The community is also waiting for some level of free support from the key architects of the technology even if it is not an obligation. However this is today a common practice.
- Integration of external contributions: even if you can establish some guidelines for external contributions in terms of quality, tests, documentation,... the "editor" will have to integrate them in the next planned releases and insure some level of tests and debugging. You may also create a "committer tax" to finance this validation and final integration step (cf: next best practice).
- Maintenance: it is not because your source code is freely available that the customers will correct all the bugs on their own. It is similar for all the changes on the third party libraries your software is relying on (database drivers and scripts, frameworks, evolution of standards, new releases of back-end infrastructure programs (OS;...). The editor will then be in charge of releasing service packs, migration procedure, ...
- Marketing tasks: The "editor" is usually in charge of updating the project web site, paying the hosting infrastructure, doing some press releases or financing other evangelization tasks...
- Administrative tasks: A sustainable software project will also require some administrative tasks. If you have one or two commercial companies, you will certainly have to incorporate them (lawyers expenses), audit them, ... You will also have to take in charge the billing of customers, the optional software insurances, etc.
Key points financed by license paid in kind
- Functional enhancements: Most of the time, customers establish a request for proposal, identify some possible products and will, of course, get a delta between all the features they wanted and what the chosen products will implement off the shelves. This is then obvious that, in the context of a sustainable software, they may decide to develop the missing features themselves and try to pay them in kind. This will allow them to influence the direction of the product to their own needs while not increasing their project TCO. That is the real strength of every open or sustainable software projects.
- Translation and internationalisation: Translation tasks are often something difficult to do (and maintain) for small and mid sized software companies. Thanks to the sustainable software paradimgs that is often something that can be easily performed directly by interested partners or customers.
Ta ease sponsorizing of new features, you can also try to use some collaborative procurement tool (ex: http://www.rap-X.com). Customer can then propose a new feature, you or any other interested programmers may quote such a development and finally one or several customers may agree to finance it. Of course, thanks to the contribution in kind paradigm, such a process may become suddenly more interesting for customers as they will be able to discount their financial participations from their future license bills.
Concretely speaking this means that certain users will pay in cash and others in lines of code. If a customer chooses the second option, he will have two main ways of contributing to the project:
1) He has some internal development resources he can assign on the project in order to develop some functional and value added enhancements.
2) He outsources the development to an external IT company (= what we call sponsorising the development of a new feature). These external IT companies are most of the time the "R&D lab(s)" that regroup(s) the key architects and developers of the technology as they often have the best technical knowledge on the code base but this may also be any system integrators that has some technical knowledge on your program.
This means that, from a consolidated perspective if you separated your product and services structure (cf. previous best practice), your revenues streams will be split between software license and development services contracts.
Of course, your "R&D Lab" may also be directly "mandated" by the product company on a long term basis in order to maintain the product, to take in charge the coordination of the community, to support the free mailing lists or to develop some major new features. This is one of the possible way to assign license revenues paid in cash to a team of dedicated full time developers in charge of managing the product on a daily basis.
Best Practice:
Assign the license revenues to software maintenance or to major code refactoring. Let the customers drive the software minor releases by accepting payment in kind.
Comments:
A software development job is NOT an integration job. Software development shall be analyzed and developed on a long term perspective from a generic manner. Services contracts are often short term focused and specific to each customer's project.
In practice this means that customers are usually not really interested in maintaining the code base (testing new drivers, updating internal libraries, optimizing the code...), in documenting the software or in refactoring the core kernel (major release cycle).
However, most of the time they will be immediately interested by adding some small new features or modules that could immediately bring to them certain functional enhancements.
The software editor will then have to take care to recruit and finance a dedicated, experienced, long term driven team of core developers that will be in charge of the tasks that the "community" does not really want to do. Thanks to cash revenues this is possible and this mechanism brings a real value added to the sustainable software approach. Customers know that there is a dedicated team of developers that will envision the future of the software, coordinate the community and maintain the existing code base. This is often a real security for customers to know that there is a "real" editor behind the software and not just some key developers that can vanish from one day to the others. They can now also focus their time on adding the new functional enhancements they needed for their internal project, something that their management may also more easily approve in terms of budgets or resources.
Key points to finance through license paid in cash
- Major kernel refactoring / major releases - The total cost of such a sub-project is often too high for one single customer. Sharing such a cost among several customers could be the best practice but is practically always tricky to realize and to coordinate as all the customers do not have the same needs, projects and budgets available in the same time.
- Community coordination and support: This will be up to the dedicated R&D team to coordinate all the actions of the community in order to be able to manage the software release cycle. The community is also waiting for some level of free support from the key architects of the technology even if it is not an obligation. However this is today a common practice.
- Integration of external contributions: even if you can establish some guidelines for external contributions in terms of quality, tests, documentation,... the "editor" will have to integrate them in the next planned releases and insure some level of tests and debugging. You may also create a "committer tax" to finance this validation and final integration step (cf: next best practice).
- Maintenance: it is not because your source code is freely available that the customers will correct all the bugs on their own. It is similar for all the changes on the third party libraries your software is relying on (database drivers and scripts, frameworks, evolution of standards, new releases of back-end infrastructure programs (OS;...). The editor will then be in charge of releasing service packs, migration procedure, ...
- Marketing tasks: The "editor" is usually in charge of updating the project web site, paying the hosting infrastructure, doing some press releases or financing other evangelization tasks...
- Administrative tasks: A sustainable software project will also require some administrative tasks. If you have one or two commercial companies, you will certainly have to incorporate them (lawyers expenses), audit them, ... You will also have to take in charge the billing of customers, the optional software insurances, etc.
Key points financed by license paid in kind
- Functional enhancements: Most of the time, customers establish a request for proposal, identify some possible products and will, of course, get a delta between all the features they wanted and what the chosen products will implement off the shelves. This is then obvious that, in the context of a sustainable software, they may decide to develop the missing features themselves and try to pay them in kind. This will allow them to influence the direction of the product to their own needs while not increasing their project TCO. That is the real strength of every open or sustainable software projects.
- Translation and internationalisation: Translation tasks are often something difficult to do (and maintain) for small and mid sized software companies. Thanks to the sustainable software paradimgs that is often something that can be easily performed directly by interested partners or customers.
Ta ease sponsorizing of new features, you can also try to use some collaborative procurement tool (ex: http://www.rap-X.com). Customer can then propose a new feature, you or any other interested programmers may quote such a development and finally one or several customers may agree to finance it. Of course, thanks to the contribution in kind paradigm, such a process may become suddenly more interesting for customers as they will be able to discount their financial participations from their future license bills.
The contents of this website are licensed under the Open Software License 2.0 or Academic Free License 2.0
 Top |
 |
