Gnome Hackers Sorting Out Differences RE:2.0 189
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."
Anyone would flip out (Score:1)
Just looking at those words makes me kind of nauseous...
History is but an endless waltz... (Score:1)
Re:I just want the accursed thing to work, dammit! (Score:1)
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.
never fight by e-mail! (Score:2)
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.
Re:Mass Flamage (Score:2)
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 just want the accursed thing to work, dammit! (Score:2)
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?
I want up-to-the-minute stability (Score:2)
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.
GNU Network Object Model Environment (Score:2)
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.
Re:Maintainers and Passionate Others (Score:2)
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 ;-)
Re:GNU Network Object Model Environment (Score:2)
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 :-)
Maintainers and Passionate Others (Score:4)
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.).
Proposed new term: "Burnt out" (Score:2)
--
Re:This can serve as the base for a ... (Score:1)
Re:This can serve as the base for a ... (Score:2)
'Flames of our lives'..
'Lists of Flame'..
'One Life to code'..
Re:To many Egos, not enough indians.. (Score:2)
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-)
To many Egos, not enough indians.. (Score:5)
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 explain... (Score:1)
Thanks,
Derek
Note to Slashdotters (Score:5)
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
Give me my GTK+2.0! (Score:1)
That said, it is interesting to watch all that's going on here. I hope they get all their stuff straightened out soon.
Correction... (Score:1)
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
Does licensing mean nothing to you? (Score:2)
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
Re:what is the techincal argument? (Score:3)
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:
Re:what is the techincal argument? (Score:5)
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
A little bit of ashdust ... after the flames (Score:1)
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
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.
Out of curiosity... (Score:3)
Re:Product Management (Score:2)
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.
Product Management (Score:5)
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.
Re:Ok, but what does that mean exactly ? (Score:3)
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
Re:I just want the accursed thing to work, dammit! (Score:2)
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.
Re:Could someone explain... (Score:3)
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-).You may have already won! (Score:1)
[Re:Competition is better...] not always (Score:1)
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).
Re:Qt GPLed? (Score:2)
Greetings Pointwood
supply and demand (Score:1)
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
Re:supply and demand (Score:1)
Why does it even matter? (Score:1)
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.
Re:Correction... (Score:1)
http://www.trolltech.com/company/announce/gpl.html [trolltech.com]
Note the date: Sept. 2000
Expectations too high - for *any* software (Score:2)
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.
Re:I just want the accursed thing to work, dammit! (Score:2)
Re:I just want the accursed thing to work, dammit! (Score:2)
Re:I just want the accursed thing to work, dammit! (Score:3)
I'm confused. KDE is GPL. Qt is also GPL. What is there to stop a "strong supporter" of the GPL from using KDE?
Re:Out of curiosity... (Score:2)
KDE does have its problems, but compared to what we see here they are small. The aforementioned Craig Black, for example.
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.
Re:Out of curiosity... (Score:3)
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?
Software Crisis? (Score:1)
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.
Re:Out of curiosity... (Score:4)
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
Re:I just want the accursed thing to work, dammit! (Score:1)
-Mike
Re:I just want the accursed thing to work, dammit! (Score:1)
-Mike
Link to flamewar (Score:1)
I have no idea on with you are talking about (Score:2)
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.
Re:Qt GPLed? (Score:1)
Competition is better for the world :) (Score:2)
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).
Recent KDE flamewar summary (Score:3)
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
Passion is a good thing (Score:3)
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.
KISS principle. (Score:2)
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.
Re:complexity (Score:2)
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.
Re:I'm confused. (Score:2)
Re:I'm confused. (Score:2)
Re:I just want the accursed thing to work, dammit! (Score:2)
You should see a psychiatrist about that, then.
--
Miguel, Windows, Gnome and the Software Crisis (Score:3)
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.
Re:Product Management (Score:2)
Re:Flaws in the open source model? (Score:2)
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.
Problems of decentralization? (Score:3)
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.
Re:Product Management (Score:2)
--
Re:Out of curiosity... (Score:2)
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.
The good thing about flame wars (Score:2)
Re:I just want the accursed thing to work, dammit! (Score:2)
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.
Re:Product Management (Score:3)
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.
This can serve as the base for a ... (Score:3)
"Thread of Geeks"
and now back to our regular programming !!!
Re:Out of curiosity... (Score:2)
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.
Mass Flamage (Score:3)
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.
Re:Out of curiosity... (Score:2)
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++.
Re:The motivation wasn't exactly like you portray (Score:2)
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 :-).
Re:Qt GPLed? (Score:3)
Re:Note to Slashdotters (Score:3)
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.
Re:Mass Flamage (Score:4)
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.
Re:Mass Flamage (Score:2)
Re:Passion is a good thing (Score:2)
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.
They're Gnomes (Score:2)
ref. - Dragonlance Chronicles
It's actually on the gnome-2-0-list (Score:4)
I think the best part is when George (the Panel maintaner) jumps in and says:
I certainly have no authority to say this ... (Score:2)
Finally... (Score:5)
Finally, a replacement for "ALL YOUR BASE ARE BELONG TO US"!
Re:Out of curiosity... (Score:2)
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.
Re:I just want the accursed thing to work, dammit! (Score:4)
Actually, Qt is GPL. GTK is not.
Unsettling MOTD at my ISP.
This is a real problem (Score:2)
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.
Whither GNOME? (Score:3)
The debacle with Evolution and Nautilus (Medusa, etc.) come to mind. Slow releases of binaries, incompatibilities...
hmmmmm (Score:3)
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? [mikegallay.com]
what is the techincal argument? (Score:4)
Re:Qt GPLed? (Score:5)
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]
You think thats a flame war?? (Score:2)
Ok, but what does that mean exactly ? (Score:2)
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,
Re:Out of curiosity... (Score:2)
Re:I just want the accursed thing to work, dammit! (Score:2)
Re:It'd DUAL LICENSED! (Score:2)
Re:Out of curiosity... (Score:4)
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.
Component architecture? (Score:2)
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. :)
--
Re:GNU Network Object Model Environment (Score:2)
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 can be the right move (Score:2)
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
Re:KISS principle. (Score:2)
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.
primitive tools/methodologies (Score:2)
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.
complexity (Score:2)
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.