Sustainable Open Source

Develop the software

Maintain software quality

Provide developer support (3rd line support)

Provide documentation

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 bug fixes and security fixes. The vendor must publish all the generally applicable 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 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 bug fixing. The vendor should also contribute all the bug 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 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.

Deploy solutions and/or provide services based on the software

Provide user support (2nd line support and/or 1st line support)

Provide part of the software funding

Pay fair share of the profit to the open source vendors or individual developers. If the integrator makes profit from deployments or services that are based on open source software then a fair share of that profit must go to the vendors or developers of that software. This applies to the initial deployment cost but it especially applies to the support cost. If the integrator makes a recurring profits than a part of that profit also has to go to the vendor or developers. These guidelines do not dictate what a "fair share" is. But it has to be more than 0% and less than 100%.

Provide feedback to the vendors. The integrator has both the right and the responsibility to report software bugs, submit suggestions for improvements, ideas for new features and so on. The vendor must provide appropriate channel for integrators to do that efficiently. The integrator will make sure that the reports and suggestions are clear and professional. Generally speaking the vendor should actively participate in the software lifecycle. E.g. integrator should take part in testing pre-release versions of the software, review the documentation, participate in localization efforts and so on. This activities are supposed to be reflected in the fees that the integrator pays to vendors. Integrators that significantly participate in software development and maintenance.

Do not abuse the services provided by vendors. Do not abuse community service. Do not abuse the paid services either. Vendor services are meant to fix bugs and maintain product quality. Their primary purpose is not to fix configuration problems. Every issue should be examined in depth by the integrator first. If it is clearly an configuration issue it should be handled by the integrator. If it is a product bug or if the situation is not clear, only then the integrator should raise the issue with the vendor. There may be cases when the integrator cannot handle configuration issues by himself due to bad documentation or lack of diagnostic features in the product. In that case the integrator should raise documentation requests and diagnostic improvement requests with the vendor.

The integrator will provide proof that the money are going to the vendors. The user can request information about the solution support services at any time. The integrator will provide all the relevant information to the user without any delay. This information has to include the data about the fees that the integrator is paying to the vendor. The user must be able to check that the integrator is keeping the promise as specified in this document. The user should clearly see how much money is going to the vendor, whether it is one-time fee, recurring fee, which entity is receiving the payments and so on.

In case that any amount of public money were used in the project (even indirectly) the previous right applies to all citizens of the country that supplied the money. Therefore in that case any citizen has the right to request the information and that information must be provided in the same way as if the user requested it. When public money is involved it is recommended to make this information publicly available even without any request.

The integrator will provide all the necessary information about the deployment to the vendor for the purpose of setting up fair fees and prices for the services. The integrator will notify the vendor in case that any significant characteristic of the project changes, e.g. if there is a significant increase or decrease in the number of users, the magnitude or complexity of the solution, etc. In such case both parties are obliged to renegotiate the agreement to keep it fair.

Provide (indirect) funding for software development and maintenance.

Prefer sustainable use of open source. The user will make his purchasing decision in such a way that encourage the sustainable open source ecosystem. The user strongly will prefer integrators and vendors that follow the sustainable open source guidelines defined in this document (or equivalent guidelines). This does not mean that the user has to select only integrators that follow these guidelines or only choose from open source solutions. What it does mean is that if the user is considering open source solution then it will prefer sustainable open source. E.g. the sustainable open source may get significantly higher score during product evaluation as opposed to solutions that do not guarantee sustainable product development.

Share part of the profit. If the user is running a business where the open source software is a crucial component then the user should share part of that profit with the vendor. This can be arranged directly (donations, sponsoring) or indirectly through integrator services. But if the user is making profit on open source then a fair share of that profit should go to the team that has created that product.

Provide feedback to the integrators and vendors. Submit suggestions and ideas for software improvements. This is important, because the ultimate purpose of the software is to serve end users. Therefore the suggestions from the users are very important for the future software development. The users should use communication channels provided by the integrators and vendors for this purpose.

Do not abuse the services provided by vendors and integrators - especially the free services. The vendors are expected to provide community services that help new users of the software. However it is expected that the purpose of these services are mostly for the users to evaluate the software. The free services are not a replacement for production support. Once the user has chosen the software for production the user has a responsibility to participate in the funding. The user should establish an agreement with the integrator or vendor for that purpose.

Make sure that the money that he pays are going to integrators that agree to these guidelines or directly to vendors or original authors. The user should use the mechanisms specified in these guidelines that the money he is paying are really going to the original software developers and maintainers.

Allow data checks for vendors. The vendors may need to check the deployment data that the integrator provides to them. The users should cooperate in these checks. The user should also cooperate with vendors in case that there is a suspicion of an integrator violating this guidelines.

Support sustainable open source ecosystem. Prefer business partners that are also supporting this model.

Personal use of open source software is always OK.

When you use open source in a company that generates profit, contribute back to the ecosystem:

Using existing open source library to build a bigger open source product on top of it. Contributing bugfixes and enhancements back to the library maintainers.

Your company is using a lot of open source products and makes profit. Distributing part of the profit to the open source projects in a form of donations. Or paying wages of several developers that work as full-time contributors to open source projects.

Providing a commercial support service for an open source product. Sending fair share of the profit to product authors.

Vendors maintain documentation for the product. The basic documentation must be public. But there is no requirement that has to be free for every use. The CC-BY-NC-ND is the minimum requirement for basic documentation. However that license prohibits commercial use of the documentation. Additional licensing of the documentation may be a source of income. But this must not prohibit the use of software. Basic documentation needed to learn the product must always be available.

Trainings may be paid services and training materials do not need to be public - assuming there is reasonably good documentation. The training must not be a requirement to start using the product.

We acknowledge that the documentation maintenance is often a problem. It is not easy to create complete documentation for a system and to maintain it. Therefore the documentation of practical projects will always be far from being perfect. Therefore the users and integrators should expect some level of incompleteness and inaccuracies and they should point them out to the vendors. Vendors should fix them as soon as possible.

There are projects that do not bring profit for integrators or users. This often happens when you start with a new technology or explore a new business idea. It is understandable that you keep the cost down. These guidelines ask for fair share of the profits. Therefore if there is no profit then the fair share of that profit is zero. This is OK. However keep in mind two things. Firstly, that needs to be repaid later when there is a profit (even indirect profit). If you start using the software without contributing to it does not mean it is OK to keep it using like this for a long term. Secondly, if you are not contributing then you are limited to community services. If you are using this approach for too long the patience will eventually run out.

Users can use community services provided by the vendor for free. But these services are limited to the "best effort" level. The vendor should publish a guidelines of what is acceptable, what is not acceptable and how to communicate: how to ask questions, how to submit bug reports and suggestions, etc.

The integrators should take some part in the software development. It helps the vendor and it also improves integrator’s understanding of the software. There are plenty of opportunities to get involved:** Test the software - before it is released. Testing the software after the release is also good, but it has quite limited value. It is much harder to fix the bugs after the software is released because there is need to maintain a support branches and so on. Testing the software right before release is much more valuable. The vendor development process should be open therefore you should be able to see the right moment to participate in the testing.

Providing commercial support services for open source product and not contributing nor funding it is bad. If you make profit that depends on the existence of an open source product you should contribute part of that profit to the product. You should contribute your time and become part-time developer of that product. Or you should spend time on documentation maintenance, localization …​ there is always a lot of work to do. If you cannot do anything like that then you should send money to the developers. But taking the money and keeping everything for yourself is not a good behavior.

You include open source component in your solution. The customer pays you a support fee for the solution. But when there is a problem with the open source component all you do is to send questions to the product mailing list. This is extremely bad behavior. You take money, keep all of them for yourself. And in addition to that you are generating extra load for the original developers. This means a short-term profit for you, but long-term cost for the product. In the end the product will starve and everybody will lose. Including you.

Providing commercial (cloud) services based on open source product and not contributing nor funding it is bad. This is similar case as the one above. If you are making profit on a product please consider contributing back.

Making patches or enhancements to the open source product and not contributing them back is bad. You may think that your work is your own. However, your work is based on work of many developers that created the product, developed the source code, wrote the documentation, tested the product and so on. Even though you are no legally required to contribute the code back you really should do it. Firstly it is paying back your debt to the community. Secondly there is a major benefit for you. If your contributions are accepted to the main product code then it will become part of the product. It will be much easier for you to maintain the functionality. Most of the maintenance work will be done by the core developers. You will not need to rework your patch for every new product version over and over again.

Create commercial closed-source product which is fundamentally based on one or more open source products and do not contribute or fund these products is very bad. Yes, the most liberal open source licenses allows this approach and what you are doing might be perfectly legal. But it is not OK on the moral side. If you want to do this then please contribute back to the community. It is the least you can do.

Using open source libraries in your commercial product and not contributing to any of them is bad. Yes, there are tens or even hundreds of dependencies in your project. You are not expected to contribute to all of them. That would not be really possible. But choose some of the libraries. And contribute to these. Contribute either manpower or money. But you should contribute somehow. Even the libraries need to survive.

Asking trivial questions is bad. Do not abuse the community services. Asking questions such as "my system is broken, please help" is not going to help anyone. Not even you. You will be ignored or you will get angry responses. They to do your own research before you ask questions. Read the documentation. Search the internet, search mailing mailing list archives and so on. Try to make some effort to solve the issue before asking questions.

Closed product development is very bad practice. There are vendors that claim to develop open source software but then do not publish complete source code. Or they publish only source code for released versions without the development history. The code changes are thrown "over the fence" once in a while. This is extremely bad practice. It is almost impossible for third parties to cooperate on such project. This may be open source by license, but it is not a good open source practice. This technique is often used only for marketing. It has a name: fauxpen source. Avoid such projects. They do not have a future.

Hiding documentation, samples or tutorials behind a paywall is bad. Do not limit access to the documentation only to paying customers. The basic documentation must be free. Everyone should be able to learn about the product for free. Of course you are not expected to give for free the things that cost you money. E.g. the trainings are usually paid service and that’s perfectly OK.