Forgot your password?
typodupeerror
GNOME GUI

Gnome Hackers Sorting Out Differences RE:2.0 189

Posted by Hemos
from the it's-like-a-family-fight dept.
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."
This discussion has been archived. No new comments can be posted.

Gnome Hackers Sorting Out Differences RE:2.0

Comments Filter:
  • by Anonymous Coward
    if they had to work on a project with components named libgnome, libbonobo, libbonoboui, libgnomeui, and so on.

    Just looking at those words makes me kind of nauseous...
  • by Anonymous Coward
    ...the three beats of war, peace, and revolution repeated throughout time. I guess the same axiom can be applied to most open-source development projects.
  • It's not about the GPL really, more about jealousy, hate and blindly following the word of the holy RMS.

    Stallman called GNOME into existence as a response to a desktop (KDE) created with a product (Qt) that did not conform to his idea of "free" software. It was free to download and to use, but did not meet some ideological criteria or another - perhaps it was only that it wasn't his.

    Later, when Qt became GPL, Stallman was not gracious - in fact instead of welcoming them to the project and looking for a united approach he called for an apology.

    A major reason why I have little respect for the man, and none for the people who still refuse to use KDE because they "support the GPL". No you don't, you support your slavish unquestioning devotion to the word of an obese, stinking communist.
  • by Anonymous Coward
    I've said it before and i'll say it again. Never fight by e-mail, mail or over the phone.

    These forms of communication are not good to express emotions. People tend to misunderstand one another way too often, and then all hell brakes loose.

    e-mail is practical, bod please do your fighting IRL.

  • But quitting because of flames? Thats the same as quitting for no reason.
    These are real people here, and you just can't entirely divide the personal from the technical. Especially with something like this, where the participants are involved because of personal passions, not just because it's how they earn a living. If they didn't care personally, they wouldn't be doing it in the first place.

    I understand that flaming is a natural, emergent part of the internet experience. But it still sucks. And it doesn't have to happen. Just as we form societies in real life, we can do it on the internet -- peer opinion means a lot on the internet (more when things aren't anonymous). If people show that they look down on flaming, that cruel words are not respected, then people will start (appropriately) censoring themselves.

    The widely espoused alternative is to "put on your flame-retardant suit" and just suck it up. That works sometimes. I certainly won't be bothered if some AC writes "fuck you, idiot" in reply. But I think there are some major negatives to doing that all the time:

    • Your sense of empathy doesn't kick in right. If you remain sensitive to flames, you'll be sensitive when writing flame material. I've seen a lot of cases where highly flame-resistant people can be short, dismissive, demeaning, and just plain cruel to innocent, though sometimes misguided newbies (among others).
    • It might leak into your real life. Being a geek I had put up a lot of walls to defend myself from the ridicule of my peers. But now I'm an adult and my peers don't ridicule me. Those walls only harm me now and they probably didn't help much in my youth either. Trying to tear them down in one environment and keep them up in another is hard. I don't think my experience struggling with this is unique.
    • You become naturally defensive. A truly well-formed argument is one that leaves room for your opponent to gracefully concede a point. If an argument involves neither side conceding any points, that's not a helpful experience. Maybe one side converted more bystanders into their camp, but ultimately some sort of concensus has to be reached -- even if it only means that the losers agree to stay silent. This is hard to come by after flaming, and seldom creates good feelings among the group.
    • Flaming tends to degrade into point-by-point rebuttal and counter-rebuttal. This is closely matching the Lincoln-Douglas debating style, which I consider the least insightful way an issue can be argued (can anyone tell I wan't pleased with my brief debating experience?) This tends towards reactionary statements, which decay towards absurdity. Seldom does anything new come out of such discussions.
    So yeah, you're going to get some flames. But I think they could be handled much more constructively by the group -- rephrasing vitriolic but valid flames into something more reasonable, matching flames with positive feedback, and having third parties confront flamers off-list. That last one particularly -- it's weird how a mail with a To: line that only points to one person is so much more intimate and personal than one that CC's the list. It makes people realize that there's individuals behind the email addresses, which usually is enough in itself to stop flaming. It also short-circuits the posturing that is behind many flames.

    More love.

  • I am a really, really big fan of GNOME. I think it's a beautiful and effective desktop environment - easily my favourite - that the GTK toolkit is fantastic (I've written a couple of GTK apps) and that it is GPLed is equally important, right, and good.

    But goddamn, that's been hard to swallow lately....

    I've been using the Ximian update service for getting GNOME, because I like the idea of getting regular updates as a tested group of binaries - with a project with as many different components as GNOME, it's tough to do all the "find newest version, ensure no compatibility issues, compile it, debug interactions" busywork yourself. The idea of a central source that would push the latest versions, tested to ensure compatibility with each other, down to my machines on a regular basis is VERY attractive.

    But the releases coming out of Ximian have been few and far between, and the last one has resulted in Sawfish crashing more often than any program I have ever used. GNOME for me started off as stable as a rock, and has become increasingly UNSTABLE as time goes on.

    It's getting to the point where I'm seriously considering dumping the whole thing, a concept that I find personally objectionable, as I strongly support the GPL and don't want to use KDE for that very reason.

    Troubleshooting hasn't been very rewarding either, as it seems that even the tarball releases of key components like Sawfish seem to occur at infrequent intervals - even though I've seen indications that the "constant Sawfish crashing" (it hits an assertation that t cannot equal zero, but does) may be a known problem, and may be fixed in CVS. You have a crash problem, fix it, and don't _immediately_ cut a new release? Huh?

    GNOME guys, what the hell is going on? Isn't this stuff supposed to get _better_ with time? What ever happened to "release early, release often"? And Ximian, where's the quality control? Where's the rapid release schedule? Where's the communication and feedback?

    If I'm a _fan_ and getting this frustrated, what must the rest of the world feel like right now?

  • Here's the issue: when a given program (or set of programs) is touted as being "stable", then I expect it to be stable. If a bug - especially a crash bug - shows up, then I expect the fixed version to be released NOW, because the existance of the crash bug in the "stable" program invalidates it as being "stable".

    I don't mind waiting for new features et al, but I do expect to get a feed of the latest bug fixes pretty well as they occur.

    The idea that the fix for the "Sawfish constantly crashes" problem that is driving me nuts might have been found, written, and applied a month ago - but is still locked up in CVS instead of being released - is driving me right around the frickin' bend.

    The Linux kernel has been really good at this. All the instability goes into the Developmental kernels, and the Stable kernels get nothing but the bugfixes - and those bugfixes are applied in very short order. Alan may like to do a lot of prereleases in between each "official" stable release, but there's a very good chance that if thge bug has been identified, there exists a tarball where it is fixed.

    It would be a VERY good thing if, every week, each patch that fixed a bug without otherwise affecting the core functionality could get rolled into a tarball and placed out there for people like me to get their paws on - the bug you fix may well be the one I'm suffering from.

  • "Originally, the GNOME project's goal was to create a component architecture".

    First time I hear it, but seems to me like a wonderful idea.

    GNU Network Object Model Environment--as shown by the title of this page [gnome.org]. It's kind of in the name. I know it doesn't just leap out and say "component!", but for the component people, "network object" is kind of a dead-giveaway. Then there is the fact that it is built on CORBA--which is all about objects working separately from one another and interacting and cooperationg via network wire protocols. ORBit is the key piece gluing GNOME together.

    So it has been there from the beginning. Maybe it has been forgotten (I still have my orginal GNOME foot shirt from the Red Hat Linux conference in 98), but it was the original intent. Many, when it began, remarked it was like OS/2's presentation manager--which was all components and CORBA.

    The fact that you haven't heard it could be seen as success or failure (since components are supposed to be seamless to end users). Bonobo is the bulk of the component work. By component, we mean objects that inherit useful, common functionality that allows them to team up with other GNOME apps. Bonobo provides those services. It's very cool stuff.

  • The problem (and I know very little about these arguments so take this with a few grains of salt) seems to be that gnome has no "leader".

    I'm sure that someone will be pissed about me saying this, but it is pretty true. That person is Miguel [ximian.com]. Now granted, he is not the only developer, but many people see him as the leader--even if it is unofficially. He helped start the whole project (with others), and he has been at the forefront from the beginning.

    As to final say, I'm not so sure. ESR has long held Linux as THE example of the bazaar--but how? It still comes down to a cathedral like decision--i.e. Linus says yea or nay. In this case, Miguel is very loath to come out and say "Your right and you are wrong, now do what I say." I for one like it.

    Is it as efficient? Probably not. But it is the true essence of Open Source software. Which has nothing to do with the GPL, but more to do with the democratic approach.

    OTOH, I am a firm believer that my code is my code--if I am the sole starter of a project, I have a certain level of say in what happens to it. But then I release under the LGPL--anyone who doesn't like what I'm doing can fork ;-)

  • But for me the distinction between object and component is important. For me, a component should be directly manipulable, and could be combined with other components to make apps without coding, or almost without coding. That's what I thought when I saw that sentence.

    Hehe. Many would argue that a properly designed object is a component, according to that definition :-)

    As it is, GNOME is all object based (even though it is in C, which takes some discipline [grin]) with the idea that it would be a component framework. All well-designed CORBA objects should function just like you said. But that's pretty tough stuff to wrap your brain around. Thus bonobo--it takes the "assumption" and makes it more concrete. Inherit/use bonobo, and you get all those nifty CORBA-based component services with no coding. It makes building components much easier for beginners. Most CORBA people start by building base classes that do all the hookups and lookup upon server instantiation. The guts live in the subclasses. Bonobo provides that. Additionally, bonobo, along with other GNOME libs, provides services used by apps and components (DnD, etc).

    I think the intent was always that GNOME would be component based. The problem (IMO) was in that most GNOME developers were GTK developers--and all of their apps are monolithic (i.e. static or dynamic linking, but ONE app space) and weren't experienced in component/CORBA development. So the GNOME team had to build infrastructure to make GNOME component based apps easier to develop. That being said, bonobo (et al) are very useful, since 95% of the component base stuff is almost always the same. So it's a good thing all around.

    GNOME was always component based--it's just that many are trying to make that much, much easier by including basic component services in the GNOME core infrastructure. How to build those services and what APIs should be there and what they should look like is the whole source of the argument (two or more differing opinions on how to build a piece of that infrastructure).

    Thanks for taking time to answering me. :)

    Never a problem :-)

  • by Kostya (1146) on Tuesday June 19, 2001 @06:51AM (#141401) Homepage Journal
    After starting with you can flame me, I am full of love [gnome.org] I read the threads, and this appears to be a little more than simple disagreement over which feature to use. It appears that the maintainers want to have the right to make decisions for themselves (i.e. what to accept and what to reject) and that others want a process for change.

    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.).

  • Burnt out: What happens to an active developer on an Open Source project who is forced to leave due to persistent flaming from the peanut gallery to which they don't have the time or energy to respond.

    --

  • ROTFL.. I think I've actually said that last one more then once..
  • How about

    'Flames of our lives'..
    'Lists of Flame'..
    'One Life to code'..
  • Unfortionatly, forking and incompatible implementations also thrive on it.

    It does look as though they came up with a 'compromise' in the case of gconf vs bonobo-conf, in the use of a wrapper, which is a good thing. Fortionatly, one side conceded in order to make things move forward.

    And there are threats in working in an open source community. The threat is that your code will be ignored or allowed to rot, and all of your time will have been in vein. In many cases, it's great if you scratch an itch, but if every program decides it doesn't want to interact with your tool, in this case, gconf vs bonobo-conf, it's worthless, and your work was in vein..

    Blech, sometimes life just sucks.. 8-)
  • 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..
  • Could someone who has a few extra minutes please give me a summary of what "bonobo" is and what the "bonobo-conf versus gconf" war was about?

    Thanks,
    Derek
  • by Panix (2408) on Tuesday June 19, 2001 @06:58AM (#141408) Homepage

    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

  • I don't use Gnome (did for a while, but I'm over that). I don't use KDE. I don't want to use anything like them. All I want is a nice toolkit that makes my apps pretty. I don't need to turn my desktop back into a windows (work|look)alike.

    That said, it is interesting to watch all that's going on here. I hope they get all their stuff straightened out soon.
  • Last I heard, QT was still under the QPL, which is a very different thing than the GPL or LGPL. KDE can't really be seperated from QT (alas, the Harmony Project collapsed), so using KDE still means using the QPL.

    Like many, I find the QPL sufficiently disagreeable that I avoid KDE, even though I think it is a better system.

    Of course, my "desktop" consists of FVWM, but I recommend Gnome to others. In the long run, I think it will "win". Types like me will choose it based on Freedom, and companies like HP and Sun will choose it because the LGPL license on GTK is a lot easier for them to swallow. They don't want to be beholden to some company named Troll Tech.

    --Lenny
  • This is primarily an open source site, man. Darwin is open, sure, but the majority of the system is not. Hell, the hardware isn't open, either.

    As for your description of KDE and Gnome as "marginally functional, amateur efforts", that's just flamebait. For the record, I was more impressed with KDE 1.0beta2 (1997) than with MacOS X (2001).

    If you like MacOS X, and the licensing doesn't bother you, then use it. I'm interested in freedom, and I sure don't get that with an Apple platform.

    --Lenny
  • by Luyseyal (3154) <swaters&luy,info> on Tuesday June 19, 2001 @09:29AM (#141412) Homepage

    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:

    • gconf info in .deb package, "GConf is a configuration database system, functionally similar to the Windows registry but lots better. :-) It's being written for the GNOME desktop but does not require GNOME."
    • bonobo gnumeric: http://www.gnome.org/projects/gnumeric/gnumeric-0. 65 [gnome.org] "Please do not package gnumeric-bonobo yet. However, NEW for this release Bug reports are now welcome for the Bonobo build. It will become the default shortly."
  • by Luyseyal (3154) <swaters&luy,info> on Tuesday June 19, 2001 @08:46AM (#141413) Homepage
    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


  • After reading the entire flaming thread (plus some more), here are my contribution of ashdusts ...

    1. It is not easy to be Humble.

    Contrary to popular believe, we human being are not known to be humble.

    Had people involved in the flamefest - anyone, - understand the importance about humility, this flamefest would have been better managed.

    2. The problem with Complexity

    One of the tap-root cause of this flamefest is the complexity of Gnome's architecture.

    Sure, Miguel is not wrong to want Gnome to follow his vision of ... "component platform", the thing Miguel (and many other Gnome folks) have forgotten is that the "component platform" thing was supposed to make a complicated thing SIMPLER.

    The underlying structure of Gnome is too complex, and until SOMEONE start to deal with that problem, Miguel's vision of getting Gnome of being a true "component platform" thing may never come true.

    And here is my suggestions -

    A. There are a whole lot of great points being aired in this debate. Why don't someone - other than those whose blood are still boiling due to the debate/flamefest - collect all the great points, and list them out in the open, for ALL to view and review?

    B. Cool Down Period - Please someone impose a cool down period for all involved. I understand that many an ego have been scratched, and a cool-down-period may heal the wounds caused by this debate. I hate to see anyone quit just because of this debate. We can always go back to point (A) - just above - and see what all of us can do with all those great points that were being aired, and use them to improve Gnome.

    B1. Those who were involved in the debate - take time off, think over what has happened, and then, think of what Gnome is all about. If Gnome's future is what you care MORE than the rough-words hewn during the debate, ignore them and continue to churn out the code you want for Gnome's sake.

    C. Havoc may have a good intention, but committee-level-decision-making-method won't fit Gnome's loose and free nature. Let Gnome be Gnome, and let Gnome become strong by the force of natural-evolution, and not the resulted of Kremlin-like central-committee I say this, you follow methodology. Let the component maintainers their free will to do whatever they want, and if what they do ends up incompatible with the general flow of Gnome, then, their "babies" will die natural death. If component A dies (or lack in compatibility), I am sure someone else will pick up the pace and launch a component A+ to take its place. The natural flow of Gnome must not be disturbed with any central-committee.

    D. Listen to the critics, ask them to help out. There are lots of people willing to offer criticisms, but not many who will go beyond that. Gnome can benefits from the critics too ! Recruit them, ask them to get involved, so that they will know more about the inner operation of Gnome, and then ask the critics to offer suggestions on how Gnome can be improved. What we need is not only the brainpower of the coders, we also need the insights of those who have offered criticisms.

    *** Note - The above are my own point of views. I may be wrong. If I am, please correct me. Thank you.

  • by Psiren (6145) on Tuesday June 19, 2001 @06:31AM (#141415)
    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.
  • I'll come out with it, then: sometimes they might not feel _good_ enough to contribute code. I was a competent engineer, but never brilliant, and my coding has slipped since I moved into management - I just don't have the time to write much anymore. But I'd like to be more involved, and just because I can't write low-level code at a good enough standard to contribute doesn't mean that I can't review design, features (and sometimes even code) and take an overview, or be involved in other ways.

    Again, I think that we should look to involve people outside the tight coding community, and make the most of the skills they (we!) have to offer, if those people _believe_. And I, for one, do.
  • by MikeCamel (6264) on Tuesday June 19, 2001 @06:52AM (#141417) Homepage
    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.
  • by JanneM (7445) on Tuesday June 19, 2001 @06:47AM (#141418) Homepage
    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
  • part of the problem with this is that more and more of the work of putting a cohesive whole together out of GNU/Linux, GNOME, KDE and other big projects, is being done by the distributors. Even the kernel itself is going that way; a typical RedHat or Mandrake kernel has dozens if not hundreds of patches over the regular Linus kernel, and is (at least in theory) better tested, balanced and tuned. With desktop environments, same deal: they're a pain to put together between all the libraries, CVS versions, snapshots, and so on, that it's hard to get them to work from source, and regular people are just grabbing whatever some distributor (RH or Ximian or whoever) packaged up for them. This is part of a trend towards complexity that I'm not all that happy about.

    I like the Unix idea of programs that do things (complicated or simple) in a fairly standalone way, with well-defined interfaces, and that can be replaced, recompiled and debugged fairly easily.

    unfortunately, all these componentized architectures that desktop environments use seem to be going in the opposite direction: everything depending on everything, hugely complicated APIs all over the place, and virtual DLL hell.

    this sounds like a losing situation to me. the good thing about it is that the unix underpinnings of the system are still there, and I can skip GNOME and KDE and their associated heaps of GUIish programs if I don't like them. but you can't really skip using a web browser at this point in time, and the current web specs are so overcomplicated that there's no chance of anyone doing a browser whose source can actually be undesrtood and debugged by mere mortals.

  • by Ian Pointer (11337) on Tuesday June 19, 2001 @09:07AM (#141420) Homepage
    Warning: This could all be rubbish, but here's what I've picked up...

    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 [gnome.org] and see for yourself 8-).
  • A "I-fed-the-trolls-and-all-I-got-was-this-lousy-shi rt" Tee shirt!


  • Imagine KDE and Gnome were two railroad companies. Now, each company wants to be the 'standard', but they can't agree, so each one lay their own railroads. Fine, problem is, the distance between the rails are different.

    Now, the train builders have to choose between the two rails. Instead of building one train that works on all railroads, they either have to choose one or the other. Now, of course, people who buys the train can refit the trains to their railroads, but this refitting is very expensive, so why bother.

    A train builder who builds for one set of rails is not really competiting against another train builder that buils for the other set of rails.

    Now, as a user, why would you care? Well, say one set of rails are put between your city and city B. You usually travel between your city and city A, so you have monthly pass. To get to city B, you have to pay an extra ticket instead of using your monthly + learning new schedules, changing trains etc etc. Waste of money and time.

    In short, common infrastructure is good. KDE and GNOME pretty much split the infrastructure in two (actually three, third one for application that hasn't/won't be changed).

  • Proof [trolltech.com].

    Greetings Pointwood
  • I think it's fair to say that heirarchy or not, people in high demand will leave an organization if they can get a job elsewhere and are unhappy with their current position. This instability make the idea of a chain-of-command suspect. I've encountered this in science, where post-docs can get paid much more outside academia...I have to attract them through stimulating work and a good work environment. It's probably true of the computer industry (years ago if not now): anger your employee and they walk.

    Imagine how this translates now to a group of talented, well-paid coders donating their time to a project. Sometimes (often?) these projects lack anyone with formal management training, and strong words fly quickly when personal contact doesn't exist between group members...digital relationships can be broken so cleanly. Look to online communities like MU* for solutions.

    Lust

  • PS: I'm a strong believer in benevalent dictatorship. The buck stops somewhere.
  • With each release KDE continues to pull furthur and furthur ahead of Gnome it's almost sad.

    You compare this childish bickering and flaming with the recent CVS freeze and almost corporation-quality organization going on at the KDE camp and the difference is clear.

    QT is now open source and it's incredibly organized. The Gnome libraries are a mess. KDE is also C++ while Gnome is C. KDE is also working on KOffice which is already completely usable and damn impressive.

    The Gnome developers who have the maturity and intelligence to do so should start helping the KDE project. While competition is a good thing it really only serves a purpose when the competition competes. Gnome isn't anymore.

    Flame away, perhaps I'm just an insane fanboy.

  • Well, "last you heard must have been quite a while ago...

    http://www.trolltech.com/company/announce/gpl.html [trolltech.com]

    Note the date: Sept. 2000

  • Isn't this stuff supposed to get _better_ with time? What ever happened to "release early, release often"?

    Does Microsoft "release early, release often"? Can you think of any major software project that does? As a developer, I like the sentiment, and we try to follow it in our own projects, but in large, complex systems like Gnome, it's unrealistic to expect an unending frequent stream of updates. Similarly, installing all the latest updates as soon as they're released is a recipe for frustration, again with any software.

    If you want stability, pick a stable version and stay with it. If you want the excitement of continally experimenting with the latest stuff, then you have to live with bugs and instability. A "stable" release just means that it's been tested by beta testers, it's not truly stable until it's been tested by everyone else, too, and then patched with the necessary fixes.

    It's your choice, don't make it and then complain about it once you experience the consequences.

  • I am sorry but I just have to argue. Compiling kde source on my own has never ever been a problem. I would get qt, ./configure, make Grab any and all kde packages that I want and run ./configure; make; make install. As long as you install kdelibs first that is the only problems I have ever had. Oh and it has worked with cvs co too. This compared to the times when I have tried to get gnome I have had to go all over the net and get a ton of packages who all seem to be unrelated only to find that package a requires b which requires a!!! I gave up on gnome with that. You can complain about gnome, but not kde. hehe and you can talk to my roomate who tried to compile gnucash hahaha!
  • The companies I have met with would rather spend the 1500 to get a pripriatory license then have to worry about a gpl thing. One place even expected me to spend 4K on devel software and wern't sure what to do when I didn't spend any of it.
  • 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?

  • Errm...that's what I was trying to say only you said it better. :)

    KDE does have its problems, but compared to what we see here they are small. The aforementioned Craig Black, for example. :) KDE as a group is very cohesive...like you said, once a decision is made, everyone pretty much goes along with it. (I too read the mailing lists :)

    They get a lot done: look at KDE...it's very mature, very stable, and has lots of applications already. They've done a very fine job and aside for the relatively long stretch between KDE 1.4 and KDE 2.0, things seem to get done in a reasonably fast manner.

  • 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.

    Sure. KDE has it's problems at times. All large open source projects do at some point. I think it is part of the natural Bazaar mode process.

    OTOH, my impression of the KDE group is that it is far more cohesive than the GNOME group. That's why they tend to get things done faster, IMHO. However, cohesiveness, as we all know from basic sociology and critical thinking classes, can lead to groupthink....anybody think KDE is subject to that?


  • I believe the is "software crisis" is a farce. People have been declaring a software crisis since the 1960s. Without a "crisis", snakeoil peddlers would have no MBAs to buy their wimpy $25,000 application servers or dynamic objected structured architecture modeling foobar chart solutions.

    What people mostly call a software crisis is usually a problem with project management or ever-changing requirements. Look at the capabilities and performance of today's software compared to that of ten years ago. It's pretty amazing.
  • Sure. KDE has it's problems at times. All large open source projects do at some point. I think it is part of the natural Bazaar mode process.

    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

  • I agree. I've been tyring to update my Gnome installation for a while, and every "update" causes more crashes and incompatibilities. It's a nightmare. And, using the Ximian tool, I sometimes get random errors (with no messages!) in the middle of a download/install. That then leaves my Gnome installation in a Bad Place(TM).

    -Mike

  • Actually, I take all that back. Just tried it again today and it installed perfectly. I'm now running Gnome 1.4 with Sawfish and it looks sweet!


    -Mike

  • Can you provide a exact link to the start of this flamewar? I guess you can read it at lists.kde.org (or maybe not?).
  • But Red-carpet does not install packages unless it has all dependencies.
    I've sometimes not been able to fetch some packages due to server-errors, but they've never created any problems, as red-carpet has just not installed any of them.

    Have you filed any bug-reports, or asked around on monkey-chat? I bet that would be more useful than just naming problems on Slashdot.
  • If I wasn't being forced to use Windows 98 at the moment, which means I can't moderate when I have points because the boxes get randomly mixed around the screen whenever I scroll, I'd mod you up :)
  • Having two 'rival' desktop environments is a very good thing for UNIX. Each has areas where they excel, and which point the way for the other. To take just a small example, Nautilus has a much higher 'prettyness' factor than Konqueror in KDE 2.1 -- so, what did the KDE developers do? They improved some features on Konqueror (the detailed list view and the file previews) in the direction of the trail blazed by Nautilus. Look for KDE 2.2 to see what I mean :). Similarly, KDE shows to the GNOME guys things to do and not do in getting a proper component and object model: it's always easier to implement something if someone else has done it first :). GNOME's panel, it's default window manager, many major applications (Pan, Evolution, ...), are all superior to KDE's.

    With two seperate environments with distinct but similar goals around, they will *both* advance faster than they would do if only one of them was around. Hell, they're both infinitely better than CDE was (and I hate to think about how much was spent on developing that).
  • by jonathan_ingram (30440) on Tuesday June 19, 2001 @09:11AM (#141443) Homepage
    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 :)
  • by miahrogers (34176) on Tuesday June 19, 2001 @06:36AM (#141445) Homepage
    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.
  • One thing about both the Gnome and KDE projects is that they do not do things the simple way. I click on a file in either one (konqueror, nautilus, or gmc) and I have to wait forever before I get to see the simple contents of the directory. Admittedly, there is a lot more to Gnome and KDE than the file managers, but this is just a simple example. The libraries and embedding may be useful, but when I do graphics, I have always steered clear of Gnome/KDE and stuck with the basic GTK/QT. After all, who needs all that fluff?

    Also, with KDE, if you are not running KDE and you start even the most simple KDE app, it has to start up a hoarde of KDE helper applications, starting nearly all of KDE, just so I can edit a plaintext file. This seems too ridiculous.

    As a programmer, I stick to more basic toolkits. As a user, I use something like WindowMaker or BlackBox and ROX [sourceforge.net]. I think ROX is great, fast, responsive, gives me all I would want out of a "desktop environment" without the crap I don't need. And as a sidenote, strict application directories, imho, are great. I really think this project deserves a lot more attention for this. After giving it a chance, it managed to actually impress me, which is more than I can say for any other program in a long long time.
  • I don't disagree that C++ reduces complexity, but there are good reasons why people haven't moved to it:

    1. Cost/Benefit ratio isn't great enough, there are a large number of applications already written in C, writing an app in C gives you a guarranteed audience of coders capable of working on your open source program. C++ does not reduce complexity well enough to make it work the price of losing that group of coders, and in many cases, learning C++.

    2. There are better alternatives. Indeed, we are already way beyond C++ as the solution to complexity. Essentially, languages such as perl, haskell, python etc are the ones you move to if you wish to reduce complexity. They reduce it by massive degrees, not the increments that C++ does,

    - they automate memory management
    - they provide high level structures like associative arrays and string manipulation right there in the language
    - they completely avoid pointer ops etc increasing reliability of cheap code
    - they massively reduce code size by avoiding unnecesary overdeclaration
    - in many cases they come with a central class archive where modules can be sourced, CPAN for perl for example
    - In every non-performance-critical case, they will perform more than acceptably for the task. Additionally, the higher level definition of the task given to these interpreters leaves open long-run dynamic optimisation etc that we see being implemented in perl 6, allowing the programs to fit themselves to the use to which they are being put in any given execution, a task difficult to achieve well in lower level languages.

    Essentially every argument that could suggest C++ as the better alternative to C, also suggests python as the better alternative to C++, and people are waking up to this rapidly. CPU cycles are, with the exception of games and other CPU hard tasks, no longer a resource to be carefully preserved.

    Applications today need several important features:

    1. Stability. It is trivial to write a stable application in perl, it is non-trivial in C or (to a lesser extent admittedly) C++

    2. Adaptability. Less code = easier to refactor.
    3. Easy interaction with other applications.

    These are all served better by the higher-level languages available today, than they are by C or C++. By all means write your X window server in C++, or your kernel in C, but a word processor? it requires too many features too quickly and too much multi-app communication to be done effectively in C/C++. The over-long engineering times of many of todays open-source applications is due to the desire to stick to C/C++, and the DLL "hell" that many people are seeing is primarily due to attempts to create components of things that should never have been done as a shared library in the first place, but as a module in a higher level language.

  • Last time I checked, about .5% of the population was willing to dump their x86 boxes and switch top MacOS X/PPC (which has serious speed problems btw) just for the desktop. Unless Quartz and Aqua become open source, this isn't even a point worth considering.
  • How about getting Linux's interactive GUI performance to equal Windows? It will never happen, if only because of the disadvantages it would introduce to other types of programs. This back and forth will never lead to anything. I value desktop performance over everything, you value open systems and generalized performance. Ideally, the two stances could be reconciled in one OS, but that isn't the case in the real world, so in the end, I use what I want, and you use what you want.
  • I am sorry but I just have to argue.

    You should see a psychiatrist about that, then.
    --

  • 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.
  • 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. You seem to imply that GNOME is somehow not commercial. Like many Open Source projects, it is indeed partially commercial. Methinks you meant to say `proprietary' rather than `commercial', which really doesn't have anything to do with an applciations license and whether binaaries are licensed for sollars.
  • Interesting insight, but not modded as such. I think you are missing something. In a closed source environment (i.e. presumably a company or corporation) if there is a technical disagreement, the decision is then made by a manager (PHB if you will). If the managers can't decide, the decision will shoot right up the ladder until someone makes the final decision. I guess that is one good thing about hierarchy within a company.

    In a closed source environment, there isn't always a hierarchy for decision making. Everyone must agree so that all the programmers are on the same page. Well, not everyone always agrees.
  • by WombatControl (74685) on Tuesday June 19, 2001 @06:33AM (#141466)

    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.

  • Interesting suggestion, but I wonder whether someone who doesn't have the time/interest to contribute code to a project should be managing the project!
    --
  • I don't understand why the Linux community shuns C++.
    They don't. They just have a long history of using C, and the C++ compilers were poor for a long time.
    If you ask me, GTK being based on C is a critical weakness.
    It's a critical strength. The GTK+ object model is much more flexible and general than the C++ model. C also makes GTK+ more portable: it is trivial to port to any platform that has a C compiler and Xlib. Actually, GTK+ isn't tied strongly to Xlib -- it abstracts the low-level graphics stuff into Glib. Glib has been ported to Win32.
    C++, if used correctly, removes complexity.
    The C stuff is infrastructure that most app developers rarely need to touch. If you want to write your app in C++, just use one of the C++ bindings [gtk.org].

    Language bindings are actually a good argument for writing GTK+ in C, since just about every language can call C libraries, but calling C++ libraries is usually considerably painful. This approach also shines for languages like Python and Scheme, whose flexible object model and typing are a good fit to the GTK+ object model.

  • Having worked (and survived) in a corporate environment for a number of years, I feel it is a good thing that flame wars are fought in the open. I have seen really shrewd managers finding scapegoats with ease to save their own asses a lot of times. Thats another plus for open source!
  • I like the Unix idea of programs that do things (complicated or simple) in a fairly standalone way, with well-defined interfaces, and that can be replaced, recompiled and debugged fairly easily.

    unfortunately, all these componentized architectures that desktop environments use seem to be going in the opposite direction: everything depending on everything, hugely complicated APIs all over the place, and virtual DLL hell.

    You need to make up your mind. Is code reuse good or bad? Is making complex programs out of simple components good or bad? Because the whole goal of component architecturs and desktop environments is to bring the concepts of specialized, optimized, single purpose components into the GUI era. The component architecture is designed to allow each GUI program to do one thing and do it well and call on other GUI programs for additional features if they're needed. Shared libraries ("everything depending on everything else") are a result of heavy code reuse; instead of each program designing commonly used features from scratch they use shared libraries.

    That's not to say that things couldn't be managed better. It would be nice, for instance, if all of the commonly used components were packaged up into a single tarball for installation so that you only had to download a small number of packages to get the system working, and maybe even a single ./configure; make; make install needed to get the whole thing working. But just as we expect that grep, bash, sed, awk, etc. will each be separately upgradeable, the individual packages still need to be separately available.

  • by The Pim (140414) on Tuesday June 19, 2001 @10:28AM (#141486)
    What sprung to my mind when I started thinking about this is that Linus is a very fine Product Manager. ... So, the question that springs to mind is - what place (if any) is there for Product Manager-type role within OSS projects?

    I think your example of Linus reveals two things: One, yes, there is a place. Two, there is an incredible synergy to having the technical lead and the product manager be the same person. In fact, I think that number two is the most important "development model" lesson of Linux.

    Simply put, Linux refutes the suggestion that putting the geeks in charge leads to feature creep, half-finished features, neglect of users, and ultimately unproductive chaos (I'm sure someone can point out examples of all of these in Linux, but when you look at the big picture, I don't think they are critical). If the dev lead takes these issues seriously, he is capable of controlling them.

    The benefits of this arrangement are considerable: The technical focus of the project is uncompromised, which results in better quality and higher developer morale. Communication overhead--especially in explaining technical considerations to a non-technical product manager--is greatly reduced. And decisions are made by the person who probably cares most passionately about the product. These factors are the heart of why Linux is so good (ESR notwithstanding).

    Granted, Linus is an unusual talent, but I think many people are capable of filling the technical lead/product manager role if they really are conscientious about both. I'm convinced that the product management skills are much easier to learn than technical--the only obstacle is that most geeks don't make an honest effort to learn them.

    So I think your suggestion of using people who don't want to code as product managers is misguided. Even with good intentions, a non-technical product manager is not in the best position to make long-term decisions. In a volunteer development effort, it's questionable whether anyone would listen to him anyway. I think the best way for such a person to help is to offer advice to maintainers, and generally raise awareness of the importance of things that developers sometimes forget about: testing, documentation, usability, user responsiveness, etc.

  • by Aceticon (140883) on Tuesday June 19, 2001 @06:48AM (#141487)
    ... Soap Opera

    "Thread of Geeks"

    and now back to our regular programming !!!

  • Actually, considering that the KDE project started 1 year before the Gnome project (summer 96 vs summer 97), and looking at the respective advancements of the two projects, I'm not at all convinced by your theory. KDE may be ahead in terms of integrated desktop, but not in terms of applications (abiword, gnumeric, graphics-related softwares, pan, etc... are way ahead or their KDE counterparts) and developper's libraries.

    Gnome's weakness is, and has always been, its file manager, which is the centralizing component of a desktop. Gmc was a failure, and Nautilus is a failure too for the moment. Its configuration tool is weak too. In the meanwhile. Kfm/Konqueror and to a lesser extent Kcontrol are KDE's greatest achievements. Hence the contrast and the difficulty to make fair comparisons.
  • by Srin Tuar (147269) <zeroday26@yahoo.com> on Tuesday June 19, 2001 @06:31AM (#141489)
    To work on a big publicly visible project, youve got to expect a large quanta of flamage to come your way- most of it ignorant babble, but some is genuine ranting of people defending their turf.

    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.

  • Actually I've heard that KParts was made because a couple of KDE developers, when drunk, claimed that they could do better than CORBA. The hacker spirit I'd say :-). But it's an invention KDE made instead of GNOME who used CORBA.

    Also GNOME uses the Gimp ToolKit which they also didn't invent themselves. The reasons for GTK over Qt should also be known by now, licensing and the fact that Qt is C++.

  • I found the article where I read that. It's up at http://www.linux.org.uk/~telsa/Trips/Talks/lca-kde .html [linux.org.uk], just search for "drunk".

    The exact paragraph:

    At this stage, we were running out of time, so he speeded up :) One huge thing that helped KDE and would probably benefit other very big projects was that KDE had the KDE Summit which was sponsored by Trolltech. When you get all the people in same place, then magic happens. At the KDE one, Matthias Ettrich and Preston Brown got drunk to the stage of claiming "We could write better than CORBA. Hic. In a day!" The next day, of course, everyone reminded them about this claim, so they had to do something about it. 36 hours later, DCOM (?) emerged. There was a similar effect with KOffice, which came on by leaps and bounds as a result of the summit. So, if you're big enough to get sponsors, get your people all in one place and watch the results pour out.

    This probably (hopefully!) isn't the whole story though :-).

  • by DeeKayWon (155842) on Tuesday June 19, 2001 @08:46AM (#141493)
    Yep, QT went GPL back in September [slashdot.org].
  • by bonius_rex (170357) on Tuesday June 19, 2001 @07:58AM (#141498)
    I think these flamewars are a sign that the project is healthy and full of vigor. Apathy does not engender flame wars, passion does. These people are passionate about thier work (much of which is voluntary).

    I do not hack GNOME, but I use it, and love it.

    I say three cheers for all the passionate geeks on all sides of this argument.
    People who are willing to donate thier time, effort and lost sleep, to put up with all the crap from thier fellow geek over the arcane details of CORBA implementation (or whatever the hell they're fighting about) have certainly earned my respect and admiration.

    Slug it out, guys. It'll just make GNOME better.

  • by oingoboingo (179159) on Tuesday June 19, 2001 @07:01AM (#141505)
    Quitting because of a disagreement is just giving up

    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.

  • That is without doubt one of the most insightful things I've read on /. in a long time. I'm unfortunatly in almost the same position and the personal cost is becoming a little too high.
  • 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.

    I suspect that you're overglorifying the flames. From reading Miguel's linked mailing list post, I got the impression that there's a number of flames coming from under-informed people who're less active with the project. If it's those people who wind up driving out some of the key contributors, it's more "bullshit" than "passion" that's causing the problem, IMO.

  • Take it up with a committee. I'm sure it's somebody's LifeQuest.

    ref. - Dragonlance Chronicles

  • by 11223 (201561) on Tuesday June 19, 2001 @06:51AM (#141518)
    If you guys are really looking for the flamewar, not just the bits that leaked onto g-h, try gnome-2-0-list's June archive [gnome.org]. The flamage begins with the post " About GNOME 2.0 - The end of a dream" by Martin Baulig, the (former) libgnomeui maintainer. It's anti-Miguel! It's anti-Havoc! It's anti-Dietmar!

    I think the best part is when George (the Panel maintaner) jumps in and says:

    Damn, I missed this whole beautiful flamewar ...
    Someone flame me quickly or I'll feel left out.
  • I certainly have no authority to say this because I don't commit code or write pacthes for the gnome project, but I for one would love to have more CORBA and reusable components into Gnome. Also, why rush to have Gnome 2.0 out of the door as soon as possible? As a user and potential application developer, I would love to see tons of new features in Gnome 2.0, both extendable and reusable. Otherwise, just call it Gnome 1.5/1.6 or August Gnome (' sounds cool, no?).
  • by b1t r0t (216468) on Tuesday June 19, 2001 @06:32AM (#141527)
    "You can now flame me, I am full of love."

    Finally, a replacement for "ALL YOUR BASE ARE BELONG TO US"!

  • As it happens, kde-devel had its biggest flamewar in at least year over the past weekend. Maybe it's something to do with Mars being so close to Earth?

    But after a few years on the KDE lists, I would say I've never seen anything comparable to the one in this story, and certainly not between real developers. On the other hand, the Linux kernel list does have some frequent, nasty squabbles. Different projects have different styles and attract types of personalities.

    But who cares? The quality of the work is what counts, not how they get there. What I think is more interesting with the Gnome feud is how, despite all the assurances that the various corporate interests are all working towards a single selfless goal, the devs clearly think in terms of corporate factions and mistrust each other.

    Unsettling MOTD at my ISP.

  • the GTK toolkit is fantastic (I've written a couple of GTK apps) and that it is GPLed is equally important, right, and good...I strongly support the GPL and don't want to use KDE for that very reason.

    Actually, Qt is GPL. GTK is not.

    Unsettling MOTD at my ISP.

  • Losing a core developer to what is basically politics is bad. It's bad for GNOME's image, it's bad for recruitment of other programmers, it's bad for those corporations who are trying to help out... it's bad only so many levels. When politics takes over, what you end up with is a hierarchy, whether you like it or not, where the folks at the top usually end up becoming stagnant in trying to deal with the damage, and the folks on the bottom are turned over so consistently there's little chance at continuity over time.

    It's time for Miguel to show some leadership and fix this thing. If Martin was the problem, then his resignation is probably its own solution. Unfortunately, Havoc's swift attempt at putting a bandaid on the development-by-committee process seems to suggest that the problem is deeper, and that problem needs to be addressed and patched quicker than an emacs bugfix. KDE's already taken the lead in the X environment, and competition is only a good thing when everyone's up for it. Chances are everyone in the group knows deep down who or what the problem is, but the more the GNOME foundation builds itself into a bureaucracy, the harder it is going to be to fix these things without lawsuits -- anybody who's been involved in any sort of volunteer-driven collective that has a respectable operating budget knows exactly what I'm talking about.

  • by BoarderPhreak (234086) on Tuesday June 19, 2001 @06:21AM (#141531)
    Personally, I feel that GNOME is losing it's focus and quality control. Issues that really should be fixed are not, and new features are dragging out.

    The debacle with Evolution and Nautilus (Medusa, etc.) come to mind. Slow releases of binaries, incompatibilities...

  • by grovertime (237798) on Tuesday June 19, 2001 @06:25AM (#141534) Homepage
    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)

    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.

    1. is this.....is this for REAL? [mikegallay.com]
  • by epfreed (238219) <efreed AT metafreed DOT net> on Tuesday June 19, 2001 @06:44AM (#141536)
    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?
  • by discovercomics (246851) on Tuesday June 19, 2001 @08:44AM (#141541) Homepage
    I'm no expert but at the kde website in the FAQ [kde.org] it says this
    Is KDE free software?

    Yes, KDE is free software according to the GNU General Public License. All KDE libraries are available under the LGPL making commercial software development for the KDE desktop possible, but all KDE applications are licensed under the GPL.

    KDE uses the Qt C++ crossplatform toolkit, which is also released (since version 2.2) under the GPL.

    It is absolutely legal to make KDE and Qt available on CD-ROM free of charge. No runtime fees of any kind are incurred.

    For more info, look here [trolltech.com],
    The Qt Free Edition (version 2.2 and later) is released under the Open Source license
    QPL [trolltech.com], and GPL. The Qt Free Edition may be freely copied and distributed, put on ftp-sites and CD-ROMs etc. Qt Free Edition is provided with no warranty and no support.

    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 [trolltech.com]
    Should Trolltech ever discontinue the Qt Free Edition for any reason including, but not limited to, a buyout of Trolltech, a merger or bankruptcy, the latest version of the Qt Free Edition will be released under the BSD license.

    Furthermore, should Trolltech cease continued development of Qt, as assessed by a majority of the KDE Free Qt Foundation, and not release a new version at least every 12 months, the Foundation has the right to release the Qt Free Edition under the BSD License.

  • You should PHP-DEV when it gets to release time and people want to merge unneeded patches into the release branch.. now thats a flame war :)
  • Well at first i have to say i am a happy KDE user. I think the KDE team did a great work on KDE2, and for me it's fast enough and perfectly useable.
    Anyway, i was wondering really what all that stuff about GNOME-2.0 means, and i'd wish to have some additional explanation.
    As i understood there was two goals in GNOME-2.0:
    1- use of GTK+-2.0
    2- changes in the architecture (between gnome core and bonobo)
    So, what exactly are the roles of bonobo, lignome and libgnome(ui) in gnome, and what exactly was at stake there ?

    Thank you all, /. crowd ;-)
  • When I'm talking about KDE being ahead I don't necessarily think of just feature sets. Both desktops offer various kinds of functionality. Some of it overlaps some of it doesn't. I'm talking about their respective philosophies of development and project management. I think that KDE developers are less prone to have such devastating flamewars because they don't have that sacred cow called the Big Design. They know that decisions made today may be overthrown tomorrow if the application requirements outgrow the present architecture. Hence they don't tend to sit and ponder what limitations their design may hit in three years time. This philosophy seems to be the exact opposite of GNOME who like to have the big design thrashed out before they proceed with coding (Look how long they took to implement Bonobo 1.0). Their design is therefore more brittle and changing it stirs more emotions. I believe this already gives KDE an edge and in the future I see them getting ahead even further. Your point about GNOME being later in the game is taken but you must remember there are far fewer KDE developers to GNOME developers. Once again a similarity between the KDE approach and the Extreme Programming methodology emerges...
  • Yeah, things took an interesting twist lately. Since KDE is now fully GPLd and uses the decidedly GPL compatible QT it should be the preferred choice of GPL zealots. On the other hand GNOME's up and coming albeit deceased file manager (go figure how that's possible) uses a decidedly GPL incompatible Mozilla for its rendering engine. Tables have turned but Richard Stalin^H^Hlman still stays in the same place. Sort of makes you question the man's integrity...
  • Right on! Lest we forget that Mozilla which is used as the rendering engine in GNOME is not GPLed or even GPL compatible. It takes more than logic it figure out GPL zealots. Take care.
  • by MSBob (307239) on Tuesday June 19, 2001 @07:11AM (#141551)
    I've watched this KDE/GNOME flamewar for the past couple of years. I came to the conclusion that GNOME is doomed to fail. Here's why.

    GNOME folks took the approach of doing BigDesignUpfront [c2.com] 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 [c2.com]. 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 [c2.com] to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork [c2.com]. 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 [c2.com] 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 [c2.com] they would progress even faster IMNSHO.

  • Originally, the GNOME project's goal was to create a component architecture

    First time I hear it, but seems to me like a wonderful idea. In fact, IMHO, it's high time to start thinking about some "component standard" of sorts, at least at the OS level. Too much time lost doing the same ****dy things once and again.

    Anybody knows more about it? Or where to find info of what's pretended (done I infer not much)? Thanks for any info. :)

    --

  • Ops. Yeah, now that you mention it, it's rather obvious :o)

    But for me the distinction between object and component is important. For me, a component should be directly manipulable, and could be combined with other components to make apps without coding, or almost without coding. That's what I thought when I saw that sentence.

    So for example, in a component-driven framework, I could make let's say an MP3 organizer combining a customized file manager component with an MP3-player component, an MP3 coder component, and probably some code to extract-set tags. I mean, that would be more like an script than anyting else. Of course the desktop cannot provide all these components, but if a framework were defined, I think many apps could give themselves component capabilities, and create big sinergies in the process (hey! look at me, next you know, I'll be working for Arthur Andersen, create big sinergies indeed!). Well, probably not the idea, if I have understood it now. Worthwhile, in any case, that "component as software object". Very. But I had been really excited by the possibility of it being that "component as externally manipulable entities" concept. Thanks for taking time to answering me. :)

  • Quitting because of a disagreement is just giving up. You want to get as many developers on a free project as you can, but they've got to be willing to stand up for themselves.

    Not always. A few years back, I ran a project that comprised a handful of sharp people who "got it" and a larger group who just didn't. (e.g. rather than reading configuration files at run time, they would look up the value of interest at development time and hard code it in "for efficiency"). Management was clearly on the side of the later camp (now, there's a long story). After about a year of trying to work things out, I came to a realization: if I left and turned things over to my second-in-command, the project could be completed in time. It would be brittle and hell to maintain, but it would be done. If I stayed it would fail, since my efforts to proselytize The Right Way had made me the focus of the flame war and was attracting way too much "help" from upper management. So, I turned it over to him, and switched to another project where I could be effective. Both get finished, while if I had "stuck to my guns" I suspect neither would have.

    Without any reference to the specifics of the Gnome situation, quitting a project can be the right thing to do.

    -- MarkusQ

  • Yeah, it sucks when I need just one application (in my case konsole) but it starts all kind of error prone shit I don't need. Konsole is a very useful application but it is deeply tied to the KDE object management which results in all kinds of bugs and problems and prevents me to easily convert it to a stand-alone app.

    Anyway, I use pwm now, which solves the many-xterms-in-one-window need for me, but I dread the day when again I will need just one tiny bit of a DE and I need tons of resources to run it.
  • A big part of the problem is that systems like Gnome are written on such a primitive foundation (C/C++) that any architectural change is extremely hard to make. People can't just develop two or three different ways of doing something and use them as drop-in replacements for one another, they have to make commitments way ahead of time and with little information. It's no wonder that that turns into a battle of wills and visions. Software tools and languages haven't progressed to the point where that kind of pluggability is easy, but by using higher-level tools than C or C++, we can do a lot better.

    I think another, related problem we are seeing is that the open source developer community represents a wide range of skills (just like most commercial programmer communities). So, if you use advanced tools and methodologies, you get a tiny developer community. If you use primitive tools and technologies (like the tools and technologies Gnome and KDE are based on), you get lots of developers, but you run into maintenance and architectural problems down the road.

    I don't have a good solution. I think things will only improve as the general level of education advances beyond what it is now.

  • By saying this, I'm begging to be flamed...here goes...

    One of the problems with Gnome is that its too complex, and one of the reasons it is too complex is that it uses C.

    C++, used correctly, reduces complexity. Anyone who disagrees with this just doesn't understand C++ and OO-programming. I attribute this to some of the success of KDE. They can do more with less code. Writing a QT app is *much* easier than writing a GTK app for a competent C++ coder. Period.

    C++ has its problems, especially with Linux. GCC is just starting to become ANSI C++ compliant. Also loading a QT app takes forever because the Linux Dynamic Linker is slow when it has to resolve a zillion vtable entries when everything is derived from QObject. However, C++ is progress in the right direction. C++ encourages OO programming which is the biggest software engineering productivity increase in the last 20 years.

    The Linux community needs to move past the traditional Unix-realm and start embracing C++. Especially for GUIs and application frameworks! They need to solve the remaining issues with C++ such as incompatible libraries.

C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Working...