Skip to end of metadata
Go to start of metadata


This page is a draft (proposal) of the final ecosystem concept. It is being discussed on the identity ecosystem mailing list (

All ecosystem members make a public promise to adhere to the following guidelines:

Component Maintainers

  • Integration: Component maintainer will make sure that their component can work well in the ecosystem. Component maintainer will spend reasonable time and effort to explore integration possibilities with other ecosystem components. Component maintainers will do interoperability testing, prepare configuration samples, describe the integration scenarios an (if appropriate) make the integration scenarios part of their usual Q&A process. Component maintainers will make any reasonable adaptations to their components if such are needed for integration.
  • Integration support: Each component maintainer will provide support to any other component maintainer for free (no support fees). This support is intended to address integration issues between components. The component maintainer promise to fully cooperate on diagnosing the issues, fixing bugs and adapting the products as needed. This will be done continually from the moment when component maintainers announces its cooperation in the ecosystem till such cooperation ends.
  • Limitation of integration support: The integration support specified above is limited to component-to-component integration. Only  to the members of component core teams are entitled to request such support. Integration support does not mean that component maintainers are required to provide free support to system integrators deploying other ecosystem products. The sole purpose of integration support is to make sure the products work together and to make sure developer-to-developer communication paths are short and efficient. Any component maintainer has the freedom to refuse such support in case that it is being abused for other purposes.
  • Community support: Each component maintainer agrees to provide a reasonable amount of free community support to general public. The purpose of this support is to allow anyone to understand the basic features and limitations of each component and to evaluate fitness of the component for a particular purpose. The support is usually limited to a generic questions that are easy to answer without a need for in-depth exploration. Such support does not include assistance with diagnostic of issues or fixing them. The support is usually executed by communication on a public project mailing list.
  • Priorities, planning and scheduling: Prioritization of integration testing, product adaptation, new integration features, addressing integration issues and any other tasks is an internal affair of each component maintainer. There are no SLAs or guaranteed response times unless they are explicitly agreed in a separate agreements. Each component maintainer does his own planning and prioritization. However, each component maintainer promises that the tasks related to integration will get the level of treatment that is usual for the importance and/or severity of the task. I.e. the component maintainers will not systematically decrease the priority of integration tasks and will not intentionally ignore requests from other teams unless there is a very good reason to do so (e.g. the other team does not provide required assistance).

System Integrators and Service Providers

  • Added value: System integrators and service providers are using several ecosystem components to build a bigger solution, enhancing existing component with a new functionality, customizing it, testing new scenarios or otherwise bring a value to the ecosystem. System integrators are expected to provide feedback to the component authors such as good bug reports, bugfix suggestions, sample configurations, documentation improvement suggestions, ideas for product enhancements, etc. In other words system integrators and service providers are expected to do much more than just "download and install" the products. System integrators and service providers are not only allowed to experiment, enhance, mix&match and customize the components, they are even encouraged to do so.
  • Integration issues: System integrators and service providers acknowledge that no software is perfect. Component maintainers put a considerable effort into integration and interoperability testing. But system integrators often go into the unknown, try new ideas and deploy to new environments which is very difficult to predict. Therefore it is natural that system integrators and service providers will discover product and integration defects. It is responsibility of the system integrator to make sure such defects are addressed and to manage the process. System integrator has to take an active part by reporting the issue, provide all the necessary details and assistance for its replication, watch progress of resource resolution, etc.
  • Services and Funding: System integrators and service providers will agree with maintainer of each particular component on the details of service agreements such as a support, trainings, consulting or similar services. The system integrators and service providers acknowledge that such services that go beyond reasonable "community support" specified above are usually not free and that a fee may be required. Therefore system integrators agree to share a part of their income from the usage of ecosystem components with the component maintainers in form of support agreements, subscription fees, donations or any similar form. The primary purpose of such fees and donations is to make sure that all parties benefits from the cooperation and that the ongoing component development is well funded.


  • Professionality: All parties promise to adhere to good engineering and cooperation standards. Keep the communication polite and efficient. Keep it to technological level as much as possible. Focus on technical issues and avoid politics and hidden agenda. Be a good and valuable member of the ecosystem. Do not avoid responsibility. Do not try to move an task that is supposed to be done by you to any other party. Volunteer to do the tasks that you can do efficiently. Do not abuse the services. All engineers are expected to have skills, training and experience appropriate for their roles in the ecosystem. Any party has the right to refuse assistance in case that proper engineering and cooperation standards are not maintained.
  • No exclusivity: These guidelines do not dictate any kind of exclusivity to any party. Any party is free to cooperate with any other party which is or is not part of the ecosystem. Every party acknowledges that there may be a competition within the ecosystem, e.g. competing products or services may be offered in the ecosystem. Any party is free to integrate with any other party inside or outside ecosystem. Although we strongly encourage open source approach such approach is not mandatory. Closed parts of the solutions are acceptable as long as all agreements and licences are satisfied.
  • Ecosystem idea: Any party that agrees to these guidelines is free to use the "ecosystem idea" for any purpose. E.g. it can be freely used to promote the products or services. Any party is free to describe the ecosystem idea and initiative in their own words and form as long as it does not conflict with the original description. However, this applies only to the ecosystem idea and initiative as a whole. These guidelines do not entitle anybody to use the name of any other ecosystem member for promotion of their product or services. An explicit bilateral agreement is needed for that and it is outside the scope of these guidelines. Please note that purely technical claims in form "we can integrate with Foo v1.2" are OK, even if used in a marketing material. Claims such as "we work closely with Foo" or "Foo is our strategic partner" are not OK unless there is an explicit agreement that allows it.


There is no need to explicitly sign any kind of agreement. The membership in the ecosystem is announced by each individual subject in a form of public promise. The subject publicly announces its promise to adhere to the ecosystem guidelines. As we are open source and almost every technical aspect of the products is transparent, each other ecosystem member can judge for himself how well are the guidelines maintained.

However, there are several actions that each ecosystem member may take to increase the impact:

  • Publicly announce the membership to the ecosystem and describe the whole ecosystem idea. You can do it by linking to these pages and/or (preferably) rephrasing it using your own words and style. You can use your web page, blog, mailing list or any other appropriate channel.
  • Spread the idea: Reach out for other projects, integrators or service providers that are not yet part of the ecosystem. Contact them and explain the idea. You can do it without asking anyone. There is no centralized control over the ecosystem idea.
  • Include yourself in the list: even though we do not control the ecosystem (and have no ambition to do so) we would like to compile a list of organizations that announced membership. If you wish so you can contact us to include you in our list.
  • No labels