Re: [cross-project-issues-dev] JFace Generics

[Doug Schaefer <dschaefer@xxxxxxx>]

On 13-08-30 2:12 PM, "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx> wrote:

>----- Original Message -----
>> From: "Doug Schaefer" <dschaefer@xxxxxxx>
>> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
>> Sent: Friday, August 30, 2013 8:42:18 PM
>> Subject: Re: [cross-project-issues-dev] JFace Generics
>> 
>> John, you are right by the letter of the law. But I think the point is,
>>if
>> the contributors want the platform to be successful, they have to be
>> sensitive to the needs of adopters. They're who make a platform
>>successful.
>> If they aren't then who are they building the platform for? (And as
>>much as
>> we don't like to talk about it, I really hate the real answer to that
>> question).
>
>There is nothing to hate in the answer - they(we) code it for their(our)
>clients (client != adopter). (My POV)
>And one does it hoping to share the maintenance burden with other
>adopters. This is how things work. This is not something that needs to be
>hidden.
>A platform is build by various adopters so they can base their products
>on it. It's not like contributors don't care for adopters needs but they
>do care about their own needs first. I've been hit by that many times but
>there is only one way to change it - step in and do the things you need,
>if they are too big start with other things till you get merit in the
>project to the state where you can have bigger influence. That's FOSS 101.

Well, that's exactly it. I think it really becomes problematic when the
number of clients represented is small. That makes a project look closed
as well since way too many adopters are on the outside.

>
>> 
>> For Eclipse to be a successful platform going forward that has to
>>change. Or,
>> yeah, we could just fork it. A lot of us who build products on it
>>already
>> have. But no one is suggesting that's the right thing to do in the long
>>run.
>> Or are we?
>
>What John suggested to me is for people to step in "then they need to get
>involved to influence the direction" that's the first and best option. As
>another one that has product on top of it the reason to fork various
>parts in various times was nothing else but these parts being set in
>stone, patches not reviewed for months and etc. Aka projects being too
>closed not being too open.

That seems contradictory to me. But anyway, we've hashed this out a
million times over the years. We know what needs to be done. We just need
to keep building the momentum to get there.

Doug.

>
>Alex
>
>
>> 
>> Doug.
>> 
>> From: John Arthorne < John_Arthorne@xxxxxxxxxx >
>> Reply-To: Cross project issues < cross-project-issues-dev@xxxxxxxxxxx >
>> Date: Friday, 30 August, 2013 11:05 AM
>> To: Cross project issues < cross-project-issues-dev@xxxxxxxxxxx >
>> Subject: Re: [cross-project-issues-dev] JFace Generics
>> 
>> Eike Stepper < stepper@xxxxxxxxxx > wrote on 08/30/2013 05:59:14 AM:
>> 
>> > >The project is it's contributors not it's API.
>> > 
>> > That sounds a little as if Eclipse projects are only playgrounds for
>> > "the cool kids". I think a project is successful if
>> > what it produces (including the APIs) is successful, i.e. widely
>> > adopted. The adopters have to be pleased, not the contributors.
>> 
>> You're definitely wrong about this part. Committers and contributors
>>will
>> always have the final say. An adopter that is not contributing has
>> *absolutely* no say in the direction of the project. This is not my
>>opinion
>> - this is clearly defined in the Eclipse charter, by-laws, and dev
>>process,
>> and is the same for most other open source projects. The historic
>>platform
>> contributors (e.g., IBM), placed extremely high value on stability and
>> compatibility. If those committers are gone and a new set of committers
>> arrives that values innovation and change over stability and
>>compatibility,
>> then that's the direction the project will take. If adopters don't like
>>that
>> direction, then they need to get involved to influence the direction,
>>fork
>> the project, etc. Even as a PMC member I have no right to value the
>>needs of
>> adopters over contributors - quite the opposite I have a clearly defined
>> obligation to enable the project's contributors to make progress in the
>> direction they want to take.
>> 
>> John
>> 
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> 
>_______________________________________________
>cross-project-issues-dev mailing list
>cross-project-issues-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev