Free and Open source software (FOSS) is a great approach to software development. Open source has proven itself many time over the years. There is currently almost no comprehensive mainstream software system that does not contain at least one open source component. Many software systems are built entirely from open source components. And there are areas where open source software is used almost exclusively. Governments and the entire public sector is are looking to open source software with great hope. Open source is a huge success. And no wonder. The freedom that open source brings is a game changer. Developers can freely cooperate on the software and many parties can contribute. It is not uncommon for companies that compete on the market to cooperate on the open source components that they use in their products. Open source has significantly changed the way how the software is created.
- Publish complete source code. Complete source code of the project must be available under an OSI-approved open source license. Without any exceptions. There must be no components that are not published. The source code must be easily buildable using generally available open source tools. The project should be usable. It should be reasonably easy to deploy, configure and run. No commercial components or commercial tools must be required to get it, build it, deploy it, run it or maintain it.
- Project is well maintained. The vendor will actively maintain the project. New stable versions of the project will be available at regular or semi-regular intervals. The project will work with recent software (operating systems, development tools) and there is no need for any obsolete component. The source code of the development version of the product will be publicly available. New commits will appear in this version immediately - at the same time as the core developers see the commits. The project will be open to contributions. There will be an easy method how any developer can make a contribution. This does not mean that all contributions must be accepted. But it means that all contributions must be considered without any unnecessary delay. The vendor will quickly react to security issues and create security fixes. The security fixes will be available to all users immediately and without any cost. The security fixes will be applicable to the latest stable version of the product, not just to the development version.
- Public bugfixes bug fixes and security fixes. The vendor must publish all the generally applicable bugfixes bug fixes and product updates. The updates must be available without any unnecessary delay. There must be no private branches reserved only to selected users (licensees or subscribers). The private branches or unpublished modified source code may be created to protect private or confidential data. However these branches must not contain generally applicable fixes and updates that are not part of the public code.
- Provide support to other vendors for the purposes of product interoperability. This includes answering questions about interfaces of your products that other vendors may ask. It also includes documentation, publication of network protocols, interoperability testing, fixing of integration bugs and so on. This support is provided free-of-charge if both vendors agree to these guidelines. In case of support to vendors of commercial software or vendors that do no stick to those guidelines a reasonable support fee may be charged.
- Maintain publicly available documentation. It is not enough to simply publish the source code. There must also be a publicly available documentation. The Creative Commons CC-BY-ND-NC license is the minimum requirement. The documentation must be reasonably well maintained.
- Provide reasonable community support for new people to get started with the product. There must be a mailing list or a forum where new users may ask questions, discuss issues and submit suggestions. The vendor is responsible for maintaining this forum and for answering the questions that cannot be answered by the broader community. However, this is provided only as a best effort service. It is not supposed to be a replacement for commercial support services that may be offered by the vendor. There are no guarantees for immediate reaction. The vendor may also ignore messages that are violating the community guidelines (rude, incomplete data, questions already answered by the documentation and so on).
- Contribute bugfixes bug fixes to the upstream projects and to the products and libraries that we use. Almost no open source product is created on a green field. There are open source components that vendors use in their products. If the vendor discovers a problem in the open source component that he is using, he should explore the situation and work with the component maintainer to fix the issue. Simply reporting the bug and waiting for the fix is bad behavior. The vendor should actively cooperate on fixing the bug. He should either invest his own time to this issue or fund the bugfixingbug fixing. The vendor should also contribute all the bugfixesbug fixes, extensions and enhancements to all the open source projects that he is using - and especially to the upstream projects.
- Pay back to the community. The vendor will surely use other open source software to do software development, run his business and so on. The vendor does not have obligation to fund this software - simply because he is funding his project and he needs every resource he has to do that. However, there must be proportionality. The benefit that the vendor provides to the ecosystem has to be larger than the benefit he receives. If the vendor maintains just one tiny project and runs his entire company on open source then it is not a good behavior. In that case such vendor needs to follow the rules for open source user. However, if the project is significant then the vendor is freed form from his other obligations as open source user.
- Vendor's primary responsibility is to provide services that deal with maintenance of software quality. Which is generally known as "3rd line support" service. This mostly means fixing software bugs. The primary purpose of the service that the vendor provides is not to diagnose and fix configuration problems. The integrators and users should be capable of diagnosing the configuration issues themselves by following the product documentation. However the line between a bug and a configuration issue is somehow fuzzy. The vendor should be quite liberal in judging the issues raised by the integrators and the community. Vendor should be prepared to cooperate on issues that cannot be clearly identified as pure configuration issues.
- The vendors should make everything public: source code, every single commit, documentation, community support communication (mailing list), bug reports, roadmap, and so on. By making everything public anyone can check the progress of software development, documentation, status of individual issues and so on. Therefore the integrators and users can clearly see how their funding is used.
Open Source Integrator
The Open source integrator Source Integrator is a subject that deploys, integrates, customizes or runs open source software for the benefit of other subjects. There are the companies that deploy open source software to customers. But these rules also apply to companies that provide services based on open source software such as telecommunication operators and cloud service providers.