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.