Identity Ecosystem plans

[Radovan Semancik]

Hi everybody ...

.. and once again welcome to the Open Source Identity Ecosystem
initiative. Thank you all for joining this effort. Most of you already
know the basic stuff as we have been discussing it using private
communication. Now it is the time to start a group discussion. The thing
to discuss is new couple of weeks would be how to evolve this
initiative. Below is an (probably incomplete) list of things to discuss
and also information to start from.

1) Ecosystem manifesto and guidelines: There is a draft of the ecosystem
description and guidelines. It is (temporarily) placed in Evolveum wiki.
I have created a domain redirect, so it can be reached by this link:

http://identity-ecosystem.org/

This text was written mostly from our (Evolveum) point of view. I've
done my best, but it may need improvement. Please feel free to review it
and send the comments.

The goal is to make (possibly shorter) and "vendor neutral", publish it
in a form of "manifesto" using some neutral domain. The "manifesto" will
have links to all the ecosystem members. And these links can lead to a
more detailed description of the ecosystem, but this time given from a
point of view of each individual member.

2) Spread the word: The ecosystem idea seems to really get some
attention. We already have a very interesting set of supporters.
However, I'm sure there are sill more organizations that would like to
join. Even though the presentation of the ecosystem is far from being
finished, it might be a good idea to spread the idea even in this early
stage. I'm thinking about writing about the ecosystem in blogs, related
discussion forums, partner network channels, etc. As the presentation is
not finished then you do not necessarily need to use the link to our
wiki. Just describe the idea in your own words and point the people to
this mailing list. The goal of this activity is not to address end
customers. The goal is to attract more ecosystem members (vendors,
integrators). I think we can start doing this right now.

3) Name. Currently we are using "Open Source Identity Ecosystem" to
describe this initiative. Shawn, Francesco and me were trying to figure
out a better name. As the saying goes, there are only two hard problems
in computer science ... therefore we could not find any good name in a
limited time that we had. We have decided to go with
"identity-ecosystem" for now and to open up the discussion to the public
as soon as possible. Therefore if anyone has any idea we are more than
willing to find a better name. The limitation is that there should be a
corresponding .org or .net domain that is not taken (or owned by someone
who is willing to donate it to this initiative).

4) Domain, logo, website design: my (secret) plan is to finish the
previous task during the summer. Parallel to this we should create a
logo, create a website design and set up the website for the
"manifesto". This will obviously cost something, both in effort and
money. Although we are still not a very rich company we are willing to
contribute part of the effort and also some money to this case. I hope
to have the "manifesto" website up and running by the end of summer
(August-September).

5) Propagate the manifesto to the world: In September-December let's use
all the means that we have to spread the word about the manifesto. This
is a "campaign" focused at general public, which includes the end
customers. My personal plans are still very fuzzy here, but I hope that
others can contribute their knowledge and experience.

6) Foundation. My original idea was that this would a just a voluntary
loosely-coupled group of organizations. That the only thing to join
would be to publicly announce to follow the guidelines. But Peter Geitz
suggested that this could take a form of a foundation. And now I see
many benefit to that. However I have very little experience with this
kind of formal organization, therefor I would like to leave it to Peter
to develop this idea.

That's all from my side. Let the discussion begin.

--
Radovan Semancik
Software Architect
evolveum.com

[Emmanuel Lécharny]

Le 01/06/15 11:27, Radovan Semancik a écrit :

> Hi everybody ...
>
> .. and once again welcome to the Open Source Identity Ecosystem
> initiative. Thank you all for joining this effort. Most of you already
> know the basic stuff as we have been discussing it using private
> communication. Now it is the time to start a group discussion. The
> thing to discuss is new couple of weeks would be how to evolve this
> initiative. Below is an (probably incomplete) list of things to
> discuss and also information to start from.
>
> 1) Ecosystem manifesto and guidelines: There is a draft of the
> ecosystem description and guidelines. It is (temporarily) placed in
> Evolveum wiki. I have created a domain redirect, so it can be reached
> by this link:
>
> http://identity-ecosystem.org/
>
> This text was written mostly from our (Evolveum) point of view. I've
> done my best, but it may need improvement. Please feel free to review
> it and send the comments.

Great job ! I still have to read it in detail, but the first paragraphs
are already depicting the domain quite accuratly.

I would add a few things in the picture, like ApacheDS, eSCIMo, Apache
OpenAZ (XACML implementation), OpenSAML too. I know a few french guys
who have created a small set of tolls (lasso :
http://lasso.entrouvert.org/) that could also fit in the picture (except
that it's GNU GPL licensed)


That brings me to think we should also consider the license issue.

Anyway, more to come latter as soon as I have read the full documenyt
(and the mail) twice !

Emmanuel

[Radovan Semancik]

Hi,

On 06/01/2015 12:35 PM, Emmanuel Lécharny wrote:
> I would add a few things in the picture, like ApacheDS, eSCIMo, Apache
> OpenAZ (XACML implementation), OpenSAML too. I know a few french guys
> who have created a small set of tolls (lasso :
> http://lasso.entrouvert.org/) that could also fit in the picture
> (except that it's GNU GPL licensed) That brings me to think we should
> also consider the license issue. Anyway, more to come latter as soon
> as I have read the full documenyt (and the mail) twice !

Yes, that would be a nice addition.

However the important thing to keep in mind here is that the "ecosystem"
should not be just a list of software projects. The ecosystem is
primarily a list of organizations that provide services (e.g. support)
for the software and solutions based on it. So, to have a software
package as a first-class citizen in the ecosystem someone must "vouch"
for it. It essentially means some company must commit to provide support
on a regular commercial level and to promise that it will resolve any
issues regarding integration with other ecosystem products. While it
theoretically can be an individual developer who commits himself, having
an established company to do it instead will probably result in much
higher confidence in the software and also in higher confidence in the
whole ecosystem.

I do not see GPL as a problem as along as there is no need to link with
it (i.e. if it is not a library). As far as I know GPL is not a problem
for stand-alone servers. But please correct me if I'm wrong.

For the record: I even do not see any problems listing closed-source
software that can interoperate - as along as it is clear that these are
NOT core ecosystem components.

[Shawn McKinney]

Thanks Radovan for taking the initiative and doing the initial work to take us to this point.  I have a friend who is a security architect & graphic designer.  I will ask her if she would be willing to design a logo for us.  Also I feel an important early task should be adopting a common set of terminology to concisely describe the features sets of these products.  

Best,

Shawn

--
You received this message because you are subscribed to the Google Groups "Identity Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to identity-ecosys...@googlegroups.com.
To post to this group, send an email to identity-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/identity-ecosystem/556C257E.8040304%40evolveum.com.
For more options, visit https://groups.google.com/d/optout.

[Emmanuel Lécharny]

Now that I have read the full document, some coments.


Le 01/06/15 13:46, Radovan Semancik a écrit :

> Hi,
>
> On 06/01/2015 12:35 PM, Emmanuel Lécharny wrote:
>> I would add a few things in the picture, like ApacheDS, eSCIMo,
>> Apache OpenAZ (XACML implementation), OpenSAML too. I know a few
>> french guys who have created a small set of tolls (lasso :
>> http://lasso.entrouvert.org/) that could also fit in the picture
>> (except that it's GNU GPL licensed) That brings me to think we should
>> also consider the license issue. Anyway, more to come latter as soon
>> as I have read the full documenyt (and the mail) twice !
>
> Yes, that would be a nice addition.
>
> However the important thing to keep in mind here is that the
> "ecosystem" should not be just a list of software projects. The
> ecosystem is primarily a list of organizations that provide services
> (e.g. support)

get it. I needed to read teh full document to see that. Makes sense.

> for the software and solutions based on it. So, to have a software
> package as a first-class citizen in the ecosystem someone must "vouch"
> for it. It essentially means some company must commit to provide
> support on a regular commercial level and to promise that it will
> resolve any issues regarding integration with other ecosystem
> products. While it theoretically can be an individual developer who
> commits himself, having an established company to do it instead will
> probably result in much higher confidence in the software and also in
> higher confidence in the whole ecosystem.

+1. You can ad that Symas supports ApacheDS

>
> I do not see GPL as a problem as along as there is no need to link
> with it (i.e. if it is not a library). As far as I know GPL is not a
> problem for stand-alone servers. But please correct me if I'm wrong.

The real pb with GPL/LGPL is that it's contaminant. But if we are to use
a GPL/LGPL component in the stack, that should not be a problem, except
for a customer that would repackage the stack and sell it (we have such
customers at Symas) : their code will now be GPL, and they would have to
give back their own developement. The thing to do here is at leats to
stress out that we have GPL/LGPL component in the stack, would we decide
to use some.

>
> For the record: I even do not see any problems listing closed-source
> software that can interoperate - as along as it is clear that these
> are NOT core ecosystem components.

Ok.


Now, some more comments on the content :

1) It would be valuable to add a picture that describes the stack by
area, not only by solution. Typically, we can imagine four different areas :
- SSO
- Provisioning/Administration
- Storage
- API

In fact, even those areas are a limited vision of the whole IDM system.
Maybe an approach where we describe each of the feature, with the
associated stack, would be interesting to have. For instance, take the
Provisioning feature : you may have a picture for that where the
following components come into play :

Syncope/Midpoint
<---------------->
ConnID
<---------------->
LDAP :
OpenLDAP
ApacheDS
i389
OpenDJ

Same schema for Federation, SSO, AccessControl, etc...


1) Regarding the business model, we like to consider Symas as a company
providing support, and nothing else. Typically, we don't want to do
integration (too time consuming, does not scale, eats too much energy
and workforce). That collides with the proposal where money goes to
system integrators and service providers, obviously !

We consider that those who actually build the bricks are those who make
the whole stack possible, and this should be rewarded.

In other words, we are in the Insurance business : what we seel,
considering our products are OSS, is an insurance our customer will be
able to call *someone* when they have an issue. Integrators, OTOH, make
this possible in a way they actually install the stack, and tune it so
that it fits the customer needs, which is a complex and dire task. This
too has to be rewarded !

The complexity here is to find a way to feed both parts, assuming that
integrators have fixed costs and a non scalable business model !This is
where we have a lot to think about...

2) One reason for the IDM companies to bill their customers based on the
number of managed identities is that it make it easy to milk customers
based on some tangible metric. We probably don't want to go there : this
is extorsion. However, some customers are small, some other are
gigantic. OpenLDAP is used by companies handling thousands of entries,
and other have millions of entries (hundred of millions, actually). Some
of them are just using 2 servers, some other have up to 40 replicated
servers, in a complex geographic topology.

I'm quite sure that all teh components in the stack will face the same
kind of toipology, especially if we have to address mobile users, who
may be frequently disconnected and reconnected on different servers.

We need to address this.

[Radovan Semancik]

On 06/02/2015 07:20 AM, Emmanuel Lécharny wrote:
> +1. You can ad that Symas supports ApacheDS

Already done. Shawn has pointed that out already.

> The real pb with GPL/LGPL is that it's contaminant. But if we are to
> use a GPL/LGPL component in the stack, that should not be a problem,
> except for a customer that would repackage the stack and sell it (we
> have such customers at Symas) : their code will now be GPL, and they
> would have to give back their own developement. The thing to do here
> is at leats to stress out that we have GPL/LGPL component in the
> stack, would we decide to use some.

I'm not sure if repackaging is GPL-infectious if done properly. E.g.
Linux distributions obviously solved that problem. We can recommend
something similar. But it is the responsibility of every organization
that does the repackaging to figure out these details.

The basic idea is that the ecosystem is just a a group of software
products that work together and organizations that are making sure that
the products will work together in the future. I do not see any need to
centrally provide downloadable images of the ecosystem. That is job for
the companies that want to make profit on the form of software
distribution. And there may be many forms: convenient packages for many
platforms, pre-integrated pre-packaged pre-configured software with a
nice graphic installer, IDM-in-a-box, IDM-as-a-service, etc. ... and
each of these may be available from a different company.

(for a suggestion of a fair business model see below)

>
> 1) It would be valuable to add a picture that describes the stack by
> area, not only by solution. Typically, we can imagine four different areas :
> - SSO
> - Provisioning/Administration
> - Storage
> - API

I like this idea. Any volunteers to make such pictures?

> 1) Regarding the business model, we like to consider Symas as a company
> providing support, and nothing else. Typically, we don't want to do
> integration (too time consuming, does not scale, eats too much energy
> and workforce). That collides with the proposal where money goes to
> system integrators and service providers, obviously !
>
> We consider that those who actually build the bricks are those who make
> the whole stack possible, and this should be rewarded.

Exactly. But first of all, the specific business model is up to the each
ecosystem member to decide for himself. I do not think it is wise to
dictate anything that affects the business of ecosystem members. The
ecosystem vendors only promise to fix integration issues with other
vendors. Nothing else. E.g. there is no promise to provide any kind of
support by a vendor to any integrator. So, integrators will usually need
to purchase some kind of support from the vendor. The details are for
every pair of vendor-integrator to negotiate individually. But I can
suggest a model that works for us:

Integrator sells a solution. There are is some amount of work to
customize and deploy the solution. Integrator will do all of that and
therefore keeps all of the profit from that to himself. But there is
also "support" part of the project. Integrator does 1st-line and
2nd-line support. But integrators are usually not efficient for 3rd-line
support (fixing product bugs). Therefore integrator is motivated to
purchase 3rd-line support from a vendor. This is also what customers
usually want. They want some "insurance" that the solution is backed by
the original vendor. We are selling the 3rd-line support services in a
subscription package that contains the support, some small donation for
future product development and also some very limited consulting
services. This is all voluntary. Integrator may or may not purchase it.
But if the price for the subscription package is right it is almost
always better for an integrator to purchase this package than waste his
own resources on inefficient fixes of product bugs, merge these to
sources after every new release, try to push them upstream, learn all
the devel rules and conventions to do that, etc.

Therefore all parties will profit:
* Integrators will profit on deployment, customization and 1st-line and
2nd-line support.
* Vendors will profit on subscription (3rd-line support) and also some
(limited) amount of consultations and services provided to integrators.

Obviously, this only works for mature and established products that have
at least 20-50 active subscriptions. Only then the subscriptions add up
to fund the development. But this is what we really want as a core
ecosystem components: established mature products that are used by a
broad community. Right?

The emerging components will probably use a different business model.
They will be funded more by professional services than by subscriptions.
And again, that's OK. Until the product matures it will need more
"personal" attention anyway. And when it matures and gains more
community attention the subscription-based model becomes feasible.

I do not claim that this will work for everybody. But it works for us.
And I do not think that we should mandate this model in any way. Yes, it
would be nice to have similar business model for all ecosystem
components. But let it evolve naturally. And voluntarily. If it does not
evolve by itself then it will probably not work anyway.

> 2) One reason for the IDM companies to bill their customers based on the
> number of managed identities is that it make it easy to milk customers
> based on some tangible metric. We probably don't want to go there : this
> is extorsion. However, some customers are small, some other are
> gigantic. OpenLDAP is used by companies handling thousands of entries,
> and other have millions of entries (hundred of millions, actually). Some
> of them are just using 2 servers, some other have up to 40 replicated
> servers, in a complex geographic topology.

That's absolutely right. We have price list based on the number of
identities. But in fact we do not really care about the number of
identities. What we care about is the overall complexity of the
solution. But there is a problem: the customers like to deal with the
pricing very early in the project. And the only thing that they can tell
about the solution is the approximate number of identities. Therefore we
use the number of identities as a (very rough) approximation of project
complexity. But this is always negotiable: if we know about the project
we can provide more appropriate pricing model for that project.

However, I do not think we need a unified pricing model for the entire
ecosystem. I even believe that this would bring more harm than benefit.
If an integrator designs a solution then he will need to identify all
the components. And determine pricing for each of them individually.
Yes, the pricing model may be slightly different. But I do not see any
major problem here. Integrators are already used to do this. As far as I
know even the price lists of big name closed-source vendors sometimes
use different pricing models for different products in the same "stack".
So if we do this we are no worse than our competition.

Yes, It would be nice to have one price list for all the components.
Even though they might be using different pricing models a one price
list can be useful. But I think it is very early for this. Again, let's
see if something like this evolves later or not. After all, this is
*ecosystem* and not a single centrally-managed company. I expect that
things will evolve naturally and they will be used because they are
useful - rather than someone mandating them centrally. The ecosystem
should be mostly self-organizing. I guess the important thing here is to
keep the communication open, share experience and cooperate. And the
magic will happen.

[Emmanuel Lécharny]

Le 02/06/15 12:08, Radovan Semancik a écrit :

> On 06/02/2015 07:20 AM, Emmanuel Lécharny wrote:
>> +1. You can ad that Symas supports ApacheDS
>
> Already done. Shawn has pointed that out already.
>
>> The real pb with GPL/LGPL is that it's contaminant. But if we are to
>> use a GPL/LGPL component in the stack, that should not be a problem,
>> except for a customer that would repackage the stack and sell it (we
>> have such customers at Symas) : their code will now be GPL, and they
>> would have to give back their own developement. The thing to do here
>> is at leats to stress out that we have GPL/LGPL component in the
>> stack, would we decide to use some.
>
> I'm not sure if repackaging is GPL-infectious if done properly. E.g.
> Linux distributions obviously solved that problem.

Not exactly. For instance, f you are to package a linux distro with some
of your software in an appliance/device, then you *have* to opensource
your code. This is what many providers are doing (the box in your
appartement that provides internet is most certainly a linux based
system, and all the software it contains has to be open source). A clear
example is what happened to linksys :

http://www.wi-fiplanet.com/tutorials/article.php/3562391

> We can recommend something similar. But it is the responsibility of
> every organization that does the repackaging to figure out these details.

Yes, absolutely. But better be ready to inform those organization
straight ahead, or even better, avoid using GLP code at all (this is The
ASF policy, for instance).

>
> The basic idea is that the ecosystem is just a a group of software
> products that work together and organizations that are making sure
> that the products will work together in the future. I do not see any
> need to centrally provide downloadable images of the ecosystem. That
> is job for the companies that want to make profit on the form of
> software distribution. And there may be many forms: convenient
> packages for many platforms, pre-integrated pre-packaged
> pre-configured software with a nice graphic installer, IDM-in-a-box,
> IDM-as-a-service, etc. ... and each of these may be available from a
> different company.

+1

>
> (for a suggestion of a fair business model see below)
>
>>
>> 1) It would be valuable to add a picture that describes the stack by
>> area, not only by solution. Typically, we can imagine four different
>> areas :
>> - SSO
>> - Provisioning/Administration
>> - Storage
>> - API
>
> I like this idea. Any volunteers to make such pictures?

We can provide some of them (especially those with Fortress).

>
>> 1) Regarding the business model, we like to consider Symas as a company
>> providing support, and nothing else. Typically, we don't want to do
>> integration (too time consuming, does not scale, eats too much energy
>> and workforce). That collides with the proposal where money goes to
>> system integrators and service providers, obviously !
>>
>> We consider that those who actually build the bricks are those who make
>> the whole stack possible, and this should be rewarded.
>
> Exactly. But first of all, the specific business model is up to the
> each ecosystem member to decide for himself. I do not think it is wise
> to dictate anything that affects the business of ecosystem members.

Not wise, nor possible :-) What is necessary, though, is that each
company has a clear price list that every other company can read when
they do build a stack.

> The ecosystem vendors only promise to fix integration issues with
> other vendors. Nothing else. E.g. there is no promise to provide any
> kind of support by a vendor to any integrator. So, integrators will
> usually need to purchase some kind of support from the vendor. The
> details are for every pair of vendor-integrator to negotiate
> individually. But I can suggest a model that works for us:
>
> Integrator sells a solution. There are is some amount of work to
> customize and deploy the solution. Integrator will do all of that and
> therefore keeps all of the profit from that to himself. But there is
> also "support" part of the project. Integrator does 1st-line and
> 2nd-line support. But integrators are usually not efficient for
> 3rd-line support (fixing product bugs). Therefore integrator is
> motivated to purchase 3rd-line support from a vendor. This is also
> what customers usually want. They want some "insurance" that the
> solution is backed by the original vendor. We are selling the 3rd-line
> support services in a subscription package that contains the support,
> some small donation for future product development and also some very
> limited consulting services. This is all voluntary. Integrator may or
> may not purchase it. But if the price for the subscription package is
> right it is almost always better for an integrator to purchase this
> package than waste his own resources on inefficient fixes of product
> bugs, merge these to sources after every new release, try to push them
> upstream, learn all the devel rules and conventions to do that, etc.

Totally agree with this description. (beside the fact that some
integrators are cheap, to say the least...)

>
> Therefore all parties will profit:
> * Integrators will profit on deployment, customization and 1st-line
> and 2nd-line support.
> * Vendors will profit on subscription (3rd-line support) and also some
> (limited) amount of consultations and services provided to integrators.
>
> Obviously, this only works for mature and established products that
> have at least 20-50 active subscriptions. Only then the subscriptions
> add up to fund the development. But this is what we really want as a
> core ecosystem components: established mature products that are used
> by a broad community. Right?

Right.

No. And it would be impossible to define it.

> I even believe that this would bring more harm than benefit. If an
> integrator designs a solution then he will need to identify all the
> components. And determine pricing for each of them individually. Yes,
> the pricing model may be slightly different. But I do not see any
> major problem here. Integrators are already used to do this. As far as
> I know even the price lists of big name closed-source vendors
> sometimes use different pricing models for different products in the
> same "stack". So if we do this we are no worse than our competition.
>
> Yes, It would be nice to have one price list for all the components.
> Even though they might be using different pricing models a one price
> list can be useful. But I think it is very early for this. Again,
> let's see if something like this evolves later or not. After all, this
> is *ecosystem* and not a single centrally-managed company. I expect
> that things will evolve naturally and they will be used because they
> are useful - rather than someone mandating them centrally. The
> ecosystem should be mostly self-organizing. I guess the important
> thing here is to keep the communication open, share experience and
> cooperate. And the magic will happen.
>

Thanks Radovan, I think we are on the same page.

[Petr Gašparík - AMI Praha a.s.]

Hi,

first of all, great idea. 

The Identity Ecosystem comes right at time when we present midPoint to potencial customers and they all ask the same:

What if this small vendor/developer goes bankrupt? Can you assure the product will continue?

Our typical response was: "No, we cannot. But look at Sun Microsystem - you are never sure." Oh, I wish Sun Waveset was opensource!

Now, we can say: "You are in better position than with other products, because or Identity Ecosystem initiative." And that's a big difference that mitigates the risk!

---------------------------------------

About pictures of solutions by area: I can volunteer that. Because I already do that for presale documents:)

Have a nice day!

Petr Gašparík

AMI Praha

[Clément OUDOT]

Hi,

first, thanks for accepting my subscription to this list!

I would like of course to add some projects on which I work to this list:
* LemonLDAP::NG (http://www.lemonldap-ng.org): WebSSO and Access Management, with support of protocols like CAS, SAML and OpenID Connect (WIP)
* LDAP Synchronization Connector (http://www.lsc-project.org): Sychronization engine (identities, groups, etc.) between LDAP, SQL databases, REST API, etc.
* LDAP Tool Box (http://www.ltb-project.org): tools around LDAP, like OpenLDAP packages, Self Service Password, monitoring scripts...

Clément.
 

[Radovan Semancik]

Hi and welcome Clement,

> I would like of course to add some projects on which I work to this list:
> * LemonLDAP::NG (http://www.lemonldap-ng.org): WebSSO and Access
> Management, with support of protocols like CAS, SAML and OpenID
> Connect (WIP)
> * LDAP Synchronization Connector (http://www.lsc-project.org):
> Sychronization engine (identities, groups, etc.) between LDAP, SQL
> databases, REST API, etc.
> * LDAP Tool Box (http://www.ltb-project.org): tools around LDAP, like
> OpenLDAP packages, Self Service Password, monitoring scripts...

I would gladly add those projects to the list .. but ... the ecosystem
is not just a simple list of software projects. Is there any
organization that can "vouch" for those projects, support them and that
can promise to provide necessary integration support? (As specified
here: https://wiki.evolveum.com/display/ecosystem/Guidelines)

[Clément OUDOT]

Of course. We try to maintain a list of these organizations for each
project. See :
* http://ltb-project.org/wiki/community#professional_services
* http://lsc-project.org/wiki/professionalservices

For LemonLDAP::NG, I will add the page soon.


Clément.

[Radovan Semancik]

Hi,

On 06/11/2015 04:17 PM, Clément OUDOT wrote:
> Of course. We try to maintain a list of these organizations for each
> project. See : *
> http://ltb-project.org/wiki/community#professional_services *
> http://lsc-project.org/wiki/professionalservices For LemonLDAP::NG, I
> will add the page soon.

Thanks. But to add these projects to the ecosystem I need a clear
statement from someone who can speak on behalf of one of these
companies. The statement should be a promise that the company will
support the products and adhere to the ecosystem guidelines. Mail to
this list is all that is needed. It just has to clearly express the
promise and it has to be clear who (which company or individual) is
making the promise.

Sorry for this kind of bureaucracy. But we need to be sure that the
promises that the ecosystem is built on are clear. Otherwise there is no
ecosystem, just another list of open source software.

[Clément OUDOT]

Fine, I'll do that in the next weeks.

Clément.

[Clément OUDOT]

Hello all,

was happy to meet you in Edinburgh!

I would like to officially join the Identity Ecosystem in the name of my company Savoir-faire Linux, as system integrator and service provider on the following softwares: OpenLDAP, LSC and LemonLDAP::NG.

So I would also like to know how to add LSC and LemonLDAP::NG in core ecosystem components (https://wiki.evolveum.com/display/ecosystem/List+of+Identity+Ecosystem+Members)

Thanks!

Clément.

 

[Shawn McKinney]

Clement, thanks for stepping forward.  I know we have some work in front of us to determine what the joining process is.  For example we wish to have the companies behind the participants to formally acknowledge the ecosystem.  That way we know the companies are ready too.  But whatever that process ends up being in the end, we need to streamline it now to get you in. 

I am in favor of your entry along with the introduction of Savoir-faire Linux, and its corresponding product mix.  Can you get your company to add a page to the website pertaining to this info?  It could be something as simple as this:
https://symas.com/identity-ecosystem/

Best,

Shawn

--

You received this message because you are subscribed to the Google Groups "Identity Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to identity-ecosys...@googlegroups.com.

To post to this group, send email to identity-...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/identity-ecosystem/CAK_oV4947kjPdzZSM8_4zRahqqMpT01sLEH1qbhmrsP%3Dt691Sw%40mail.gmail.com.

[Clément OUDOT]

2015-11-20 15:10 GMT+01:00 Shawn McKinney <shawn.micha...@gmail.com>:

Clement, thanks for stepping forward.  I know we have some work in front of us to determine what the joining process is.  For example we wish to have the companies behind the participants to formally acknowledge the ecosystem.  That way we know the companies are ready too.  But whatever that process ends up being in the end, we need to streamline it now to get you in. 

I am in favor of your entry along with the introduction of Savoir-faire Linux, and its corresponding product mix.  Can you get your company to add a page to the website pertaining to this info?  It could be something as simple as this:
https://symas.com/identity-ecosystem/

Thanks for the feedback, I will contact my company to set up this page.

Would it be possible to add my email clemen...@savoirfairelinux.com to this group? I don't see how to do it on the Google group page.

Clément.

[Francesco Chicchiriccò]

Just send an e-mail to

 identity-ecosy...@googlegroups.com

from clemen...@savoirfairelinux.com, and follow instructions.

Regards.

-- 
Francesco Chicchiriccò
Tel +393290573276

Amministratore unico @ Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/

"To Iterate is Human, to Recurse, Divine"
(James O. Coplien, Bell Labs)

[Clément OUDOT]

2015-11-20 15:24 GMT+01:00 Francesco Chicchiriccò <francesco.c...@tirasa.net>:

On 20/11/2015 15:20, Clément OUDOT wrote:

2015-11-20 15:10 GMT+01:00 Shawn McKinney <shawn.micha...@gmail.com>:

Clement, thanks for stepping forward.  I know we have some work in front of us to determine what the joining process is.  For example we wish to have the companies behind the participants to formally acknowledge the ecosystem.  That way we know the companies are ready too.  But whatever that process ends up being in the end, we need to streamline it now to get you in. 

I am in favor of your entry along with the introduction of Savoir-faire Linux, and its corresponding product mix.  Can you get your company to add a page to the website pertaining to this info?  It could be something as simple as this:
https://symas.com/identity-ecosystem/

Thanks for the feedback, I will contact my company to set up this page.

Would it be possible to add my email clemen...@savoirfairelinux.com to this group? I don't see how to do it on the Google group page.

Just send an e-mail to

 identity-ecosy...@googlegroups.com

from clemen...@savoirfairelinux.com, and follow instructions.

Thanks!

[Radovan Semancik]

Hi Clement,

Welcome on board.

I have added SF Linux to the list of system integrators.

As for adding the products as core components, we do not yet have definitive rules on that. But the common practice was:
1. The products have to be open source
2. There is a company that provides professional support for the products
3. The company should also participate in the product development
4. The company is OK with the ecosystem idea: https://wiki.evolveum.com/display/ecosystem/Guidelines
(the most important part from practical point of view is the integration support to other ecosystem members)

So, if Savoir-faire Linux is the company that matches this description then I see no obstacles to add the products as core ecosystem components.

Later, the application of a new ecosystem member will be most likely based on voting. But that is not yet settled. And I think all of us will be happy to include more members at this early stage - as long as we share the same values.

-- 
Radovan Semancik
Software Architect
evolveum.com

[Clément OUDOT]

2015-11-23 10:44 GMT+01:00 Radovan Semancik <radovan....@evolveum.com>:

Hi Clement,

Welcome on board.

I have added SF Linux to the list of system integrators.

Thanks a lot for this.

 

As for adding the products as core components, we do not yet have definitive rules on that. But the common practice was:
1. The products have to be open source

Yes. LemonLDAP::NG is under GPL, LSC is under BSD.

 

2. There is a company that provides professional support for the products

Yes :
* LemonLDAP::NG  : http://lemonldap-ng.org/professionalservices
* LSC : http://lsc-project.org/wiki/professionalservices

 

3. The company should also participate in the product development

Yes, I'm working on these projects for the name of Savoir-faire Linux, but I should mention that Savoir-faire Linux is not the owner of the products, they are community softwares.

 

4. The company is OK with the ecosystem idea: https://wiki.evolveum.com/display/ecosystem/Guidelines
(the most important part from practical point of view is the integration support to other ecosystem members)

Technically, LSC and LemonLDAP::NG are compatible with a lot of LDAP servers, and LemonLDAP::NG implements a lot of SSO standards (CAS, SAML, OpenID, OpenID Connect).

Savoir-faire Linux agrees to cooperate with other ecosystem members, we're already doing this with a lot of partners, see https://www.savoirfairelinux.com/en/partenaires/communautaires

 

So, if Savoir-faire Linux is the company that matches this description then I see no obstacles to add the products as core ecosystem components.

Later, the application of a new ecosystem member will be most likely based on voting. But that is not yet settled. And I think all of us will be happy to include more members at this early stage - as long as we share the same values.

Great, we will follow the rules as soon as they are published.

 

Clément.