On 13-08-30 2:12 PM, "Aleksandar Kurtakov" <[email protected]> wrote:
>----- Original Message ----- >> From: "Doug Schaefer" <[email protected]> >> To: "Cross project issues" <[email protected]> >> 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 < [email protected] > >> Reply-To: Cross project issues < [email protected] > >> Date: Friday, 30 August, 2013 11:05 AM >> To: Cross project issues < [email protected] > >> Subject: Re: [cross-project-issues-dev] JFace Generics >> >> Eike Stepper < [email protected] > 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >_______________________________________________ >cross-project-issues-dev mailing list >[email protected] >https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
