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
this is where the gconf vs bonobo-config thread starts. Some Gnome hackers, notably Havoc, definitely do not want bonobo to be a requirement for gconf. Some Gnome hackers, notably Martin, think a bonobo-ized config system would be much better.
Both parties are attempting to predict future usage of gconf/bonobo-conf, as not a lot is dependent on gconf right now. AFAICT, all parties expect more of the core stuff to use the configuration database.
I'd kinda like to see the bonobo-conf for 2.0. According to a few posts in the thread, the gconf API has problems already and that a bonobo reimplementation would fix those problems as well as add the benefits of componentization. Since this is a new major release, I don't see why Havoc is so concerned with backwards compatibility for the gconf API since they already planned to wrap it.
but then, I've always been partial to the Linus Torvalds development kernel approach: ok you convinced me it's a good idea. Let's see what broke!
:-),
-l
References:
Help cure AIDS, cancer, and more. Donate your unused computer time to worldcommunitygrid.org. Join Team Slashdot!
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!
Have the KDE crowd had any similar problems? There will always be dissagreements about how to go about things, but it always seems to me that Gnome is trying to do too much and isn't getting anwhere. At least, not anywhere stable.
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.
IANAGH, but as far as I know, the main goal of 2.0 is to move it to GTK+2.0, Pango et. al., which is a highly nontrivial task. Moving everything to a pure component architecture at the same time was apparently considered, but it was decided that doing that as well would be trying to do too much at the one time.
As I understand, nobody has said that GNOME should not move to libgnomeui, just that it shouldn't be done at the same time as the move to GTK+2.0.
If I'm terribly, tragically wrong on this please feel free to flame...
/Janne
Trust the Computer. The Computer is your friend.
Bonobo is the new GNOME component architecture, heavily influenced by Microsoft COM. The flame war seemed to start over bonobo-conf (or bonobo-config - I think these are two different programs, but people seemed to use them interchangably) versus GConf (the current GNOME configuaration system. Originally, bonobo-conf was going to be a wrapper for GConf, but apparently Miguel + Ximian thought that GConf had major design flaws, so they (well, Dietmar Maurer ) created a new system with bonobo-conf. When this became apparent, Havoc (maintainer of GConf) was upset that they had done this whilst originally telling him that it would be a wrapper, and that the new bonobo-conf had problems that GConf already addressed (like overridable default settings). Cue flamage. I think that parts of libgnomeui were changed to use bonobo-conf, which annoyed people even more.
For more accurate info, read the GConf mailing-list archives and see for yourself 8-).as I strongly support the GPL and don't want to use KDE for that very reason.
I'm confused. KDE is GPL. Qt is also GPL. What is there to stop a "strong supporter" of the GPL from using KDE?
It wasn't really a flamewar, and isn't of the same importance as the release coordinator quitting.
:)
One of the more abrasive characters in KDE circles is called Mosfet (real name Daniel Duley I think). He implemented much of the KDE 2 theming/widget styling support, as well as the image management software Pixie. He has a habit of finishing big batches of code about a week after the KDE code freeze dates, and then stamping his feet until he's allowed to check the code into CVS.
A while back, people were trying to reorganise the kdebase package, and split some of the less essential sections into two new packages: kdeaddons and kdeartwork. Mosfet had about seven or eight window border themes in kdebase, and they wanted him to move the less used ones into the addons package. He refused. Similarly for the less used widget styles. Then Mosfet developed a new widget style, which they wouldn't let him commit to CVS because it was past the feature freeze deadline for 2.2.
Mosfet, upset at this, decided to remove almost all his themes & styles from the KDE CVS, including the new default widget style. When this didn't get the reaction he expected, he removed Pixie from CVS as well (this is fair enough - there's no real reason for Pixie to be in the kdebase package anyhow: it's a distinct complete application).
A few days later, and with a cooler head, he's moved the styles KDE actually needs back into their CVS server. The rest will either go back in the future, or be a seperate download (i.e. from kde.themes.org).
And that's about the most exciting dissent to happen within KDE development for the last 18 months
-- Help Digitise the Public Domain at DP.
At least the programmers are passionate about what they think is right, which means they are probably going to end up with a GREAT solution. Better than a world where the programmers just accept whatever comes their way even if it's a bad solution to the problem.
But other than that, I really hope they calm down the flamewars. Having a passionate discussion about something and harrassing or insulting someone else (often on something totally not related to the subject) will ruin relationships and break apart a good development team. If it's bad enough to drive someone to resign, it's pretty bad.
Miguel: I do believe strongly on the vision of making GNOME a component platform: implementing well documented interfaces all over the system; reusing interfaces to improve programmer efficacy and to make a system that is fully scriptable.
I still believe in this, because I have seen Windows do an exceptional job at this, and I am sure we can do better than they can, I believe strongly that Open Source can build a platform that is as good and better than Microsoft can.
I realize Miguel is full of love right now and will not mind a little flammage. It took Microsoft at least a decade and hundreds of millions of dollars to get its COM/OLE architecture in place and stable enough for widespread use. The reason has to do with the time consuming task of taming code complexity and killing the bugs. In the face of such mounting complexity and the never ending pressure to produce, it's no wonder that emotions are running high within the Gnome development team. In my opinion it will take the Gnome (and possibly the KDE) programmers another ten years of hard work before we can see the kind of stability that the Windows desktop is now enjoying. I hope I am wrong in my assessment. By that time the world will be thinking of new things, especially new operating systems to replace Windows and Linux/Unix.
The software world is in a deep crisis characterized by low reliability and low productivity. It is time that the free software community realizes the seriousness of the crisis and begins to confront it. We need to form a reliability forum where we can assess the nature of the problem and formulate effective solutions. I think software engineering is due for a major overhaul. We need to reassess our current approach to software engineering at its most fundamental level. Needless to say, I don't think we are doing right. I think that we all took a wrong turn way back when and that is the reason why it takes so long for projects like Windows, Gnome and KDE to iron out the kinks and add new bug-free features. But I'll leave it at that.
Frankly, flame wars in large development projects aren't really surprising. Whenever you have a group of exceptionally bright people with differing ideas you're bound to get some conflict. That's true for an open source project, a television show, or any other type of collaborative effort.
What makes situations like that spin out of control is when there's no one in charge. Decentralizing development is good to a point, but when there isn't one person responsible for solving these disputes and ensuring that development goes forward, you end up spinning around in circles. Linux has Linus (and to a certain extent Alan Cox and others) as having a good deal of responsibility for the Linux kernel. You need to have someone willing to step up and ensure that things go smoothly.
This is certainly a good case example of how open source development isn't a panacea. Even OSS isn't immune to the kind of managerial problems that are inherent in any kind of collaborative enterprise. I hope that the GNOME team manages to get things back on track and continues to put out some quality software.
"Thread of Geeks"
and now back to our regular programming !!!
I think Martin was making a good contribution, and he had many good ideas. I also think Havoc (among others) should turn down his flamthrower a notch.
But quitting because of flames? Thats the same as quitting for no reason. Any technical decisions can be sorted out- ultimately by appealing to Miguel or the board, and everyone agreeing that the main branch will honor the decision.
Quitting because of a disagreement is just giving up. You want to get as many developers on a free project as you can, but theyve got to be willing to stand up for themselves.
Yep, QT went GPL back in September.
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.
The debacle with Evolution and Nautilus (Medusa, etc.) come to mind. Slow releases of binaries, incompatibilities...
I think the key is - SO FAR. Not that I don't hope it all works out in a cheery, mutually-acceptable fashion, but it doesn't seem headed that way.
is this.....is this for REAL?
great comedy company.
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