Business Models and Best Practices Best Practices II) Software and License Management Software Release Cycle ManagementSoftware Release Cycle Management
As your software will now be open to third party contributors, you will have to include this variable into your software release cycle. Managing software planning is not a trivial task even when having all the development resources available internally. Managing software planning in a virtual context where each contributor has its own objectives, deadlines, methodology,... is a tougher one.
Sustainable Software is then very closely related to open source community based project management.
Of course, sustainable software has some real advantages. As it does not entirely rely on free work and on the availability of some external charitable contributors, the software editor can always try to enforce the use of a certain methodology, try to impose certain deadlines and try to require a certain level of tests and quality insurance in order to better integrate all the external contributions.
Best Practice:
Your software planning will rely on external contributors, so try to enforce as much as possible certain deadlines and a certain level of quality. This is not because you can pay your license fee in kind that you can develop what you want, the way you want and when you want.
Comments:
External contributions are usually managed and coordinated by a Technical Committee that regroups all the key architects and developers (="Committers"). This is then the role of this Technical Committee to try to impose to other contributors:
Respect of deadlines: Acting as an editor, the Technical Committee is in charge of managing the software release planning. The customers have to accept that their internal programmer(s) in charge of developing certain software extensions in compensation of their license should be until a certain extent directly "coached" by this Committee during this development phase.
Quality: Develop some programming guidelines. External contributions should be integrated as fast as possible without having committers to spend days to refactor all the contributed code. Do not hesitate to refuse a contribution if it is not quality proof, correctly tested and integrated in your program. It is up to the contributor to work on the level of quality you require for your project not the opposite.
Documentation: Require a complete documentation on the provided enhancements. If possible the documentation should be already integrated with the existing ones without requiring any additional work.
Practically speaking, the core team of developers (the committers) will still always have a lot of assistance, integration, testing and debugging work to do especially to coach new developers in the community. So do not forget to include such time in your software planning. A good practice would also be to bill this work through a "tax" assigned to committers that can of course be compensated in kind by some free license (cf. best practice: Managing external contribution vs payment in cash).
Sustainable Software is then very closely related to open source community based project management.
Of course, sustainable software has some real advantages. As it does not entirely rely on free work and on the availability of some external charitable contributors, the software editor can always try to enforce the use of a certain methodology, try to impose certain deadlines and try to require a certain level of tests and quality insurance in order to better integrate all the external contributions.
Best Practice:
Your software planning will rely on external contributors, so try to enforce as much as possible certain deadlines and a certain level of quality. This is not because you can pay your license fee in kind that you can develop what you want, the way you want and when you want.
Comments:
External contributions are usually managed and coordinated by a Technical Committee that regroups all the key architects and developers (="Committers"). This is then the role of this Technical Committee to try to impose to other contributors:
Respect of deadlines: Acting as an editor, the Technical Committee is in charge of managing the software release planning. The customers have to accept that their internal programmer(s) in charge of developing certain software extensions in compensation of their license should be until a certain extent directly "coached" by this Committee during this development phase.
Quality: Develop some programming guidelines. External contributions should be integrated as fast as possible without having committers to spend days to refactor all the contributed code. Do not hesitate to refuse a contribution if it is not quality proof, correctly tested and integrated in your program. It is up to the contributor to work on the level of quality you require for your project not the opposite.
Documentation: Require a complete documentation on the provided enhancements. If possible the documentation should be already integrated with the existing ones without requiring any additional work.
Practically speaking, the core team of developers (the committers) will still always have a lot of assistance, integration, testing and debugging work to do especially to coach new developers in the community. So do not forget to include such time in your software planning. A good practice would also be to bill this work through a "tax" assigned to committers that can of course be compensated in kind by some free license (cf. best practice: Managing external contribution vs payment in cash).
The contents of this website are licensed under the Open Software License 2.0 or Academic Free License 2.0
 Top |
 |
