Slashdot Mirror
Gnome Hackers Sorting Out Differences RE:2.0
jacobito writes "Perhaps this hasn't been posted because it could ignite a flame war, but here goes: The gnome-hackers list has been the center of some high drama lately. Martin Baulig, the Gnome 2.0 release coordinator, resigned this weekend due to disagreements over the use of bonobo-conf versus gconf and his license to implement architectural changes more or less unilaterally. Through the ensuing melee, fingers have been pointed both at individuals and at corporations, harsh language has been used, and at one point Miguel de Icaza made the memorable proclamation "You can now flame me, I am full of love." Really, though, neither the bickering nor the technical details are what make this affair newsworthy--what is exciting about this is watching a decentered, non-hierarchical, mostly-cooperative group of talents work through the process of getting along with each other and settling disputes, all without resorting to imposing a single dictatorial will upon the group (so far). To that end, Havoc Pennington has posted a draft of a Gnome Enhancement Procedure to provide a structured change process which will hopefully prevent future flamefests. Good reading."
Miguel makes the point again and again throughout the threads that most of the flaming is from people making statements based on little or no information--i.e. people who did not write the code making statements about the code that are misinformed or just false. If you read it, you'll see that most of the arguments are started with developers and only worsened by non-maintainers crying for process. Most of the maintainers are coming to consensus (albeit slowly and with much replying back and forth).
For the "Is this why GNOME is [so slow/sucks/isn't as cool as KDE]?" people, this has nothing to do with GNOME really. How many times have people on the kernel lists gotten into these arguments? We have the basic thing happening here: people who write the code don't want to have to go through a committee to enact changes, and people who don't know a whole lot about what they are talking about are making very passionate claims in all sorts of directions.
I'm not on the list. I just read the list. I'm not taking sides, since I clearly don't know enough to say anything one way or the other. But for the GNOME naysayers and the prophets of doom, just read the threads. This is typical Open Source/Bazaar/Free Software conflict. It's pretty easy to see if you read the mailing list. But of course, that requires some time and forethought as well ;-)
It will work itself out eventually. The developers will come to a consensus. But people need to calm down and quit clammoring for committee rule. That's the whole reason people develop this stuff--personal freedom. It's like free speech: if you want it, you have to take the good and the bad. Same with free software--or so we claim ("software is speech", etc.).
"Doubt your doubts and believe your beliefs." -- Switchfoot, Ode to Chin
Thanks for the post, is was an insightfull read to look into the logs.
But I gotta say, in all of the posts, I *NEVER* saw anyone say 'I could be wrong'. All I saw was 'I gave you a better way, and you rejected it'. No where in any of the posts did their seem to be any respect for the individual at the other end of the line. A little bit of charm, perhaps, but no real 'I respect you, man'..
One has to wonder if this is becouse working in a virtual environment leads to less personal relationships with your peers..
-- I'm the root of all that's evil, but you can call me cookie..
Just a quick note to all you slashdotters. The GNOME project is not dead. The GNOME project is not falling apart. In fact, things are going quite well. In every software project of this magnitude, free or not free, flamewars break out amongst developers occasionally, and are generally solved. The difference here is that GNOME is kind enough to be free in not only its software, but most of its mailing lists. They are not able to immedialtly cover things up like their closed source competitors.
Here is a better summary of what happened this past weekend. The release coordinator, Martin Baulig, has been working *very* hard and at an astonishing rate. His school work was suffering, and some people were criticizing a technical decision that he had made. Martin got very frustrated, and made a post that he probably shouldn't have in a tone that he probably shouldn't have. But, honestly, all of us have said things that we really didn't mean to when we have been frustrated. As a result of his post, a massive flamewar developed concerning the technical decision itself, maintainership of GNOME, how decisions are made, etc. In the end, it appears that only constructive discussion is going on now to put in place a process for proposing changes to GNOME before they are made. Havoc Pennington has written a nice process similar to the Python Enhancement process. While it is in discussion now, and will likely change a lot, it has very much promise!
As a long time GNOME user and a developer, I am actually *more* excited about GNOME right now after seeing a damaging argument turn into something productive. Every project is going to have bumps, but the measure of the project's maturity is how they deal with it. GNOME certainly hasn't handled it perfectly, but the GNOME development community is learning from its mistakes, and working to prevent them and grow in the future. So, stop complaining about "GNOME is dead", "the linux desktop is dead", and spouting off useless insults. It is clear to me that not only is GNOME alive, but it is growing in maturity.
Jonathan LaCour
The main issue is whether or not Gnome 2.0 will be bonobo-ized. Martin resigned because he fervently wanted 2.0 to be bonobized. Instead, the goals for 2.0 have been lessened to porting to gtk 2.0 and some other odds and ends.
Bonobo is a cool component architecture. It's more complicated, but supposed to be much more flexible than KParts. Do some google research or dig around on gnome.org to find out more about it. I'm kind of sad that the core components won't be bonobo-ized for 2.0, there's lots of neat stuff a Gnome programmer could do. However, most of the other folks appear to feel that bonobo-ization would be biting more off than they could chew for the projected 2.0 release.
STill, I wish them luck.
-l
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
In the commercial world, you have people who are, to some extent, both inside and outside projects, with little power other than negotiation, and who are often looking not just at technical, but also external issues - Product Management. I'm not saying that we should turn the OSS movement over to middle managers (aargh, run away!), but the role of a Product Manager is an interesting,and often very useful one. Typically, they keep everything together, calm egos, make sure that documentation, testing, engineering, PR and all the other bits get seen to, and have the overall responsibility for making it all happen - getting a release out of the door. Their role is both more and less than project managers, and they typically (in the commercial world) sit on the interface between "customers" and "engineers", taking an overview of what features are most important IRL, etc..
What sprung to my mind when I started thinking about this is that Linus is a very fine Product Manager, in some ways, in that he takes a broader view than just a technical one. He's also a Project Manager, in that he has great technical input (may his guru-ness continue for ever), but he does more than that, too.
So, the question that springs to mind is - what place (if any) is there for Product Manager-type role within OSS projects? Don't forget - and I'll say it again - I'm not advocating handing over OSS to Middle Management. But there are people with good skills out there who maybe don't want to code on the projects that they really care about (maybe it's too deep for them, maybe they haven't got the time, whatever), but have real skills and experience to bring to bear. Can we use them? Should we?
I know that I'm going to be flamed for this post, but I really believe that as we move into the mainstream, we need to look beyond just code, and take a broader view. This is _one_ way - and maybe not even a very good way, but one _suggestion_ of a way as to how we might do that. We believe (I hope) that we can take the best bits of processes and systems, and make a bigger whole than the commercial world tends to - here's one piece we might "borrow". Or maybe not.
Oh, and BTW, yes, I'm a Product Manager. See - I'm "out" now.
I've always been amazed at the lack of flames in KDE dev circles. I'm not a KDE developer, but I read the lists, and follow just about all developments. There are some pretty variant views among the developers, and flames coming in from outside, but once a choice is made, it seems that the developers as a whole accept it and move on.
But then, there exists a whole group of people who work to extend communication between all the developers - from organizing lots of face to face time to interviewing and profiling all the developers (you feel like you're doing it for a reason if you've been interviewed and elevated to minor celebrity status). I think that that area has helped quite a bit.
And then there's one observation that I have that might amuse some people. I think the KDE team works well togther because of the stupid Qt license flap, which still continues in the post-GPL Qt era. Trolls pretty much limited themselves to this[1], which was an absolute non-issue among the developers: "Oh, you're telling me I can't write and then run my own code? Well, watch *this*!", but it bound them together.
Interesting idea, eh?
[1] Now we've got the obnoxious Craig Black (and if you're a gnome user who is pissed at his pro-KDE antics, he turns it up to 11 on the KDE news sites). He's the first troll to get under my skin in about a decade (all those AOLers and Delphoids let loose on usenet in that era showed me the futility of anger against the dumb). If you ever wanted to advocate *anything*, look up his writings, and do the exact opposite.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Sometimes, but other times the frequency and intensity of technically-related flamage gets too much. You spend all your time either arguing, preparing for the next argument, lobbying on the side to bring influential managers or staff onto your 'team', or losing sleep worrying about a combination of all of the above.
This happened where I work...having to deal with the emotional stress of constantly having to deal with flaming and dissent from the leader of another development group within the company has basically lead to our group refusing to engage in any discussion with them at all. This was tacitly supported by management, as they knew they would probably lose a large chunk of our group if the relentless 'technical' infighting continued.
It's a shitty compromise...things don't work as well with the 2 teams in virtual isolation from each other, but it's preferable to having one whole team walk. I guess the point is that too much 'technically' related flaming really does get you down after a while, and I can understand why someone would want to resign a position over it. It's not 'just giving up'...it's finally deciding that having to deal with egomaniacs with poor social skills and a hair-trigger e-mail client just isn't worth the personal cost.
I think the best part is when George (the Panel maintaner) jumps in and says:
Finally, a replacement for "ALL YOUR BASE ARE BELONG TO US"!
--
"Open source is good." - Steve Jobs
"Open source is evil." - Microsoft
Actually, Qt is GPL. GTK is not.
Unsettling MOTD at my ISP.
As a gnome user, but not a programmer, I have been trying to follow the argument since yesterday. However, I have no idea what the argument is *really* about. Not the ego-who-can-make-decisions argument, but the bonobo vs. gconf and GNOME 2.0 argument. Can someone give a quick sum up of the two (?) positions?
And just in case you think they might change their minds later and try to close it back up and make it nonfree there is this
GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.
The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.
KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.
Your pizza just the way you ought to have it.