Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


Structure of the ecosystem

Few large companies offer wide range support as Master Service Provider (MSP). For example Atos or CS.

Branded SMEs work as sub contractor of the MSPs specialized for a given project as Project Service Provider (PSP). For example Obeo, Itemis, Adacore

This type of ecosystem is easier to manage by End User companies. Additionally, it can give additional opportunities to the small companies.

We should create guidelines for contracts for support contracts around Polarsys.


How to ensure that a bug is fixed in a timely fashion, given that the Polarsys WG does not have enough ressources to provide such services ?

A solution could be the following:

  • Users that want professional support subscribe to a professional services offer provided by a Branded Polarsys Provider, which could include:
    • Advice, explanations regarding the use of the tools;
    • Bug fixes;
  • In order to distinguish from the Polarsys WG and therefore be able to have a sustainable business model, Branded Polarsys Providers must offer additional added value, which could be :
    • the provision of validated binaries that are not provided by the Polarsys WG, and
    • the provision of customer-specific releases when there is an urgent and important bug to be fixed;
  • To provide for VLTS, support contracts should include the following best practices:
    • All patches should be given back to the Polarsys LTS branch,
    • unless there is a good technical or confidentiality reason provided.
  • The Polarsys WG would provide to its members a demo version only to avoid competing with Branded providers.

Open questions:

  1. Support Contracts are accessible only to Polarsys members ?
  2. who controls the Polarsys VLTS branch ?
  3. What if there is no Branded provider in a given area ?

Feature Request

Feature requests should be treated the same way:

  • When someone needs a new feature, he does it as part of a contract with a Branded Polarsys provider;
  • The development should be given back to the Polarsys LTS branch, unless there is a good technical not to do so; this way, users are sure not to pay two times for the same feature;

Open questions:

  • Is it possible to find a system that allow users sharing the development costs ?
    • If we use a system based on good will, we are likely to end up in a situation where urgent needs are funded by individual users, no matter the Polarsys roadmap, and non-urgent needs will remain unfunded forever;
    • A mandatory system is likely not to be approved.

Configuration Management is a transverse issue to Bug Fix and Feature Requests

Too many versions tends towards a custom development model and lowers economy of scale. In order to save money and allow affordable support, we need to tend to COTS.

Back to the top