Difference between revisions of "Polarsys/UseCases"

From Eclipsepedia

Jump to: navigation, search
(Bug fix)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=Support without software change=
+
=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
  
=Bug fix=
+
This type of ecosystem is easier to manage by End User companies. Additionally, it can give additional opportunities to the small companies.
How to ensure that a bug can be fixed.<br>
+
Support subscription for the tools they use? => ensure quick fix
+
  
# Users that want professional support subscribe to a professional services offer provided by a Branded Polarsys Provider.
+
We should create guidelines for contracts for support contracts around Polarsys.
# Branded Polarsys Providers must offer added value in addition to raw Polarsys added Value. This added value could be providing validated binaries that are not provided.
+
  
Support contracts should include best practices:
+
=Support=
* All patches should be given back to the Polarsys LTS branch
+
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 ?<br>
* Or there should be a good technical or confidentiality reason explained.
+
 
Support Contracts are accessible only to Polarsys members.
+
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:
 +
# Support Contracts are accessible only to Polarsys members ?
 +
# who controls the Polarsys VLTS branch ?
 +
# What if there is no Branded provider in a given area ?
  
 
=Feature Request=
 
=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=
 
=Configuration Management is a transverse issue to Bug Fix and Feature Requests=
Two many versions tends towards a custom development model and lowers economy
+
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.

Latest revision as of 10:57, 30 May 2012

Contents

[edit] 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.

[edit] Support

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 ?

[edit] 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.

[edit] 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.