Reason 1: GnomeGoals
Haven't you dreamed of having consistent codebase in your project? What about consistency through out most projects that come from the open source foundation hosting your project? I definitely wish this was the case in Eclipse.org land. Even if Gnome developers haven't achieved it everywhere they did it in many areas. Remember that even collecting and structuring the data is something that most other projects haven't tried to do!!!
Reason 2: Forward looking developers
No "if it ain't broke, don't fix it" mantra. The difference here is outstanding - even if the problem is damn hard Gnome developers work hard to get it fixed ASAP, in many Eclipse projects we wait for the problem to hit us hard and try fixing it at a time when it's way harder to do it thanks to many depending on the broken behaviour and the relevant no longer part of the community. Others (like the maven guys) take it to the other extreme - make stable releases depending on alpha software. If you want a proof - run mvn and watch for plexus-container-default 1.0 (alpha-8, alpha-9, alpha-9-stable-1!... alpha 30) coming your way. Many of the projects initiated to fix long standing problems have their hard first steps and left bad taste in some early adopters but most of them end up becoming de-facto standards.
Reason 3: Get things done(aka real Community)
You can see core developers going and adopting various other applications to their latest change in some underlying library. And there is also the opposite direction - developer spots a problem in one application and tries to fix it in the underlying library so it doesn't pops up in other places. This behaviour is what we heavily miss in Eclipse land.
- How many of us use internal/non-api packages and don't help the other project to properly define an api?
- How many of us has copied code from another eclipse.org project and let it stagnate there?
- How many of us actively removed deprecated stuff (commands vs. actions, etc.) ?
- How many of us started using underlying libraries stuff instead of our home-grown classes?
- How many of us has tried to fix the problem in the underlying platform bundle when we spot one (swt anyone?)?
I know everything is not perfect in Gnome land and my statements are pointing the good parts only but that's what we have to point out, right? Instead of pointing failures (they are always obvious), people need to point out what others are doing better than them so we can all improve.
Whatever people might say about Gnome - as a developer I can only say that they are on the right path and sooner or later the technical excellence will pay off.
P.S. I'm a years long KDE user but I seriously consider moving to Gnome 3.6 as it fixes one of my last concerns (notifications) and Gnome Shell really really has the best work-flow for my taste.
6 comments:
A real breath of fresh air - thanks!
I do like the GnomeGoals. I'm not sure how we would replicate something like that at Eclipse, given that we have many dozens of different projects with different goals and different audiences, but I'm willing to explore the idea. We're always looking for new ideas on how to better engage the community and make things easier. The adoption of Git/Gerrit, for example, was motivated primarily by a desire to make it easier for folks to contribute to projects. I know that we can do a better job with issue tracking.
In terms of consistency, we're pushing in that direction with the introduction of the common build infrastructure (CBI), a Maven repository, and common project project pages with better search and navigation, to name a few. Consistency is difficult, though, in such a large and diverse project community. Projects like to have flexibility to do things the way that they feel is best for their developers and community. We permit this within a framework while trying to provide attractive services (like CBI) that encourage projects to adopt consistent practices rather than shove them down their throats. I'm always looking for ways that we can improve on consistency without being unnecessarily burdensome or restrictive on projects.
With regard to 'Forward looking developers', this varies widely from project-to-project and suffers somewhat from perception issues. The Eclipse Platform project, for example, is widely regarded as conservative, yet they did engage on a pretty extensive reworking of years-old APIs to revitalize the platform with the 4.x stream. The m2e project moves pretty quickly as well.
How many of the things you list under "Get things done" are you guilty of and why? I'm not trying to be adversarial. I'd like to understand if there is anything that we can do institutionally to address these concerns. Are there changes that we can introduce into the Eclipse Development Process that can fix these issues?
Wayne, It's not only Gnome Goals, there are the LibreOffice EasyHacks/HardHacks, Mozilla, KDE and so on similar programs. It's not about infrastructure - Gnome guys do it with wiki and bugzilla. It's like we are too afraid to change things which is a showstopper for new blood. This might pave the road to enterprises but it makes the road to developers hearts really bumpy.
Sure, Git/Gerrit, Hudson, Tycho are improving things but on the infrastructure level not on the codebase level.
"Projects like to have flexibility to do things the way that they feel is best for their developers and community." Probably that's part of the problem. Many Eclipse.org developers sees Eclipse.org as kind of sourceforge/hosting solution while gnome developers think their project is Gnome.org not ekiga/gedit/anjuta/etc. This kind of attitude will be really hard to chainge. It's not like the foundation can enforce it, it has to come from inside people which is something gnome guys have.
About how many things we(as in Linux Tools) are guilty of - all of them!! I haven't come with this list out of nowhere it's based on real world problems I faced. It's a problem to get this fixed in a single project but it's because of how people look at eclipse.org. The release train is the best part of Eclipse Developement and that's the way to guide people in the wright direction. By adding an item everytime a project join and fail the train builds based on that (there are enough tools to enforce whatever one wants in Java land).
While you're entitled to your opinion, I just feel like the Gnome developers don't listen to the users. There's nothing wrong with introducing new features, but removing them for no reason? Completely changing the system? It would have been one thing to keep the classic-style interface and release gnome shell along with it for the users to choose, but they had to go ahead and just change the whole deskop. What they had with Gnome 2 was good, almost every distro used it by default, but they had to come along with Gnome shell and shit all over their success. There's a difference between being "Forward-looking" and changing things just for the sake of change.
Keep in mind that KDE is also reexamining notifications for the next release: http://drfav.wordpress.com/2012/07/31/the-notifications-issue-part-2-the-status/
http://drfav.wordpress.com/2012/07/19/the-notifications-issue-part-1-the-problem/
I'm late I know, but I just read your post -- catching up on stuff I missed during holidays.
I feel like replying now because I feel very much like you do.
It seems to me that Gnome has many, many problems though. Many developers are gone, lack motivation, and couldn't make any real decision about moving to a higher-level language (and come up with "things" like Vala ;)). It is clearly Sun's fault for not freeing Java earlier, or we could have lived in a very different world.
Also, the original excitement (that lasted long enough) is gone.
However the good points you quote are true, even if I think they're not specific of Gnome: they're the standard bullet points of a good old Free Software community.
The 'problem' with Eclipse it's that it's an Open Source foundation. You got it right comparing it to Sourceforge, because there are many, many projects at Eclipse and little discussion between them excepted about infrastructure.
Eclipse members have no common goal other than the release train. Even technology-wise, where Eclipse could show consistency, the practices are very different from project to project.
But indeed Eclipse members are for the most part corporate developers. Most of them are passionate developers, but they didn't come to the Eclipse community the same way Gnome devs. did: I think there's a lack of ambition and of political goal. It's just the production of useful tools.
You said it right: it's a showstopper for new blood, and developers hearts beat for projects elsewhere.
If you're at the ECE next week I'd love to discuss this over a beer. :)
Post a Comment