Business Models and Best Practices Best Practices I) Company Organisation Legal structureLegal structure
Usually a classical software company based on a proprietary program has one R&D department and one Professional Service department. The former aims to enhance the software on a mid and long term basis, the latter to help and assist customers (or partners) during the implementation phases. As the software is proprietary, only the software editor may make some changes in the program code. All the software development cycle can then be centrally managed, billed and controlled.
This situation changes when open sourcing or sourcing your software under a sustainable license. Customers and partners are now able to directly contribute to the code in order to debug or enhance it. This firstly means that the software editor does not have any more the exclusivity of providing services on the source code (adding new features, selling support,...). The professional services activities may even enter in direct conflict with the interest of other partners. It is then critical for the editor to adopt a partner neutral attitude among all these possible future contributors.
Moreover one of the main goals of opening access to the source code is to save and protect the intellectual property rights of the software for all the stakeholders and on a long term basis. Keeping all the software intellectual property and exploitation rights inside the same company that employs all your staff and that sign all your consulting and development mandates is clearly not risk free. Any major lawsuits or treasury problem may directly lead to the bankruptcy of the company and the lost of the software IP and other exploitation rights in some legal battle.
Best Practice:
It is clearly indicated to separate the product and the operating/services company in two distinct independent organisations.
Comments:
Ideally the product organisation should be an empty shell without any fixed employees and with a minimum of liabilities in order to reduce all the possible risk of bankruptcy or lawsuits near to zero. This will allow you to save the software asset on a long term basis and provide a good argument on the perennialityof your program for all your customers and partners. This is especially valid if you are a small or medium sized organisation.
From a legal point of view the product organisation may be an association or foundation (similar to the Apache Foundation especially if you do not plan to make any profits with your software) or a standard commercial company. This product organisation could be a virtual company without any direct staff but only with a network of indirect partners in charge of reselling the software and offering a wide range of related services.
If you plan to open a commercial software company and in order to keep a fair attitude regarding other key external contributors you may even think about creating some incentives program such as a Stock Options Plan. This would typically be in the spirit of a sustainable software project mainly based on meritocracy (the ones that contribute the most get more decision power = more shares).
You may then decide to open a second operating and services oriented company that will become a kind of "Shared Consulting and R&D Lab". Thanks to the contribution in kind mechanism, customers will now be able to mandate this organisation to develop additional features (= sponsorizing the development of a new feature). So in place of getting direct license revenues to finance your R&D division, you will be able to manage services contracts.
Of course you can manage some kind of reselling exclusivity between your first product company and your second services oriented company (everybody may redistribute your product for test and development purposes but not everybody may become an official reseller). But this is clearly not in the spirit of sustainable software projects that try to privilege community and collaborative work. This means that, most of the time, you will not get any form of reselling exclusivity. Your services company will be only considered as one of the possible resellers that will perhaps have better skills on the technology.
So in practice, you will have to manage two different hats:
1) a software vendor hat that tries to keep a partner neutral attitude while reselling license to other resellers and customers
2) a professional services hat that offers a wide range of value added services on the technology.
The last point to note is that, as your "Consulting and R&D Lab" will have the largest experience with the program, you will often be mandated directly by customers or even indirectly by other partners/resellers to be involved in some new development projects. So you do not really have the risk to loose all the services contracts.
Of course there are still other manners of financing sub-projects for example by assigning license revenues among all the partners involved in the development of the program. You can check some of them in the next best practices.
This situation changes when open sourcing or sourcing your software under a sustainable license. Customers and partners are now able to directly contribute to the code in order to debug or enhance it. This firstly means that the software editor does not have any more the exclusivity of providing services on the source code (adding new features, selling support,...). The professional services activities may even enter in direct conflict with the interest of other partners. It is then critical for the editor to adopt a partner neutral attitude among all these possible future contributors.
Moreover one of the main goals of opening access to the source code is to save and protect the intellectual property rights of the software for all the stakeholders and on a long term basis. Keeping all the software intellectual property and exploitation rights inside the same company that employs all your staff and that sign all your consulting and development mandates is clearly not risk free. Any major lawsuits or treasury problem may directly lead to the bankruptcy of the company and the lost of the software IP and other exploitation rights in some legal battle.
Best Practice:
It is clearly indicated to separate the product and the operating/services company in two distinct independent organisations.
Comments:
Ideally the product organisation should be an empty shell without any fixed employees and with a minimum of liabilities in order to reduce all the possible risk of bankruptcy or lawsuits near to zero. This will allow you to save the software asset on a long term basis and provide a good argument on the perennialityof your program for all your customers and partners. This is especially valid if you are a small or medium sized organisation.
From a legal point of view the product organisation may be an association or foundation (similar to the Apache Foundation especially if you do not plan to make any profits with your software) or a standard commercial company. This product organisation could be a virtual company without any direct staff but only with a network of indirect partners in charge of reselling the software and offering a wide range of related services.
If you plan to open a commercial software company and in order to keep a fair attitude regarding other key external contributors you may even think about creating some incentives program such as a Stock Options Plan. This would typically be in the spirit of a sustainable software project mainly based on meritocracy (the ones that contribute the most get more decision power = more shares).
You may then decide to open a second operating and services oriented company that will become a kind of "Shared Consulting and R&D Lab". Thanks to the contribution in kind mechanism, customers will now be able to mandate this organisation to develop additional features (= sponsorizing the development of a new feature). So in place of getting direct license revenues to finance your R&D division, you will be able to manage services contracts.
Of course you can manage some kind of reselling exclusivity between your first product company and your second services oriented company (everybody may redistribute your product for test and development purposes but not everybody may become an official reseller). But this is clearly not in the spirit of sustainable software projects that try to privilege community and collaborative work. This means that, most of the time, you will not get any form of reselling exclusivity. Your services company will be only considered as one of the possible resellers that will perhaps have better skills on the technology.
So in practice, you will have to manage two different hats:
1) a software vendor hat that tries to keep a partner neutral attitude while reselling license to other resellers and customers
2) a professional services hat that offers a wide range of value added services on the technology.
The last point to note is that, as your "Consulting and R&D Lab" will have the largest experience with the program, you will often be mandated directly by customers or even indirectly by other partners/resellers to be involved in some new development projects. So you do not really have the risk to loose all the services contracts.
Of course there are still other manners of financing sub-projects for example by assigning license revenues among all the partners involved in the development of the program. You can check some of them in the next best practices.
The contents of this website are licensed under the Open Software License 2.0 or Academic Free License 2.0
 Top |
 |
