Public Bug Tracking and Open-Source Policy

Observer writes "Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy? A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature. Between Gnome's public bug tracker and similar trackers from distributions which released (and still distribute) the buggy version, months of debate provide an interesting case-study in the way front-line users and developers interact for better or for worse. What lessons can be learned here for release planning, bug triage, and marketing for a major open source project?"

Comments

+1 Transparency

[alain94040]

Transparency still beats all other alternatives.

Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.

Re:+1 Transparency

[NineNine]

Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.

Huh? If they're public and open, the end use can see them. What are you talking about?

Re:+1 Transparency

[Vectronic]

I think he might mean that there is no "Show Forum Discussion" option during installation, likewise, the "Bug" section of a website is usually hidden under terrifying things like "Developer Section" etc, ie: unless the (average) user bumps into a problem and goes hunting online, or bumps into it randomly, they won't know about it.

Re:+1 Transparency

[Anonymous Coward]

It's like CP. It's there but you don't really see it unless you look for it.

--BadAnalogyGuy

Re:+1 Transparency

[pjt33]

Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.

Huh? If they're public and open, the end use can see them. What are you talking about?

My emphasis.

Re:+1 Transparency

[rtfa-troll]

As with me and a few others of the true slashdot elite, you probably spend every spare waking hour of your life following the minute details of the latest comment to report of a bug in sylpheed alpha four; never even sparing a moment to read code or try to replicate the bug yourself. However, you probably have to accept that even most of the people on slashdot have something else better to do with their lives (or at least more exciting), for example watching the countdown to the end of 64 bit time_t and posting on their favourite freenet BBS about exciting upcoming changes in the fifth to seventh digits. These more so called "normal" individuals will probably never even realise he discussion took place.

Re:+1 Transparency

[Vectronic]

I see what you did there, you covertly pointed out the 'bug' in his 'user'.

Glad we caught that little bugger, lest we have a public discussion about it, and no one ever finds out.

Oh forget it...

Re:+1 Transparency

[einhverfr]

I think it is important to keep lots of communication between end users and developers, but htis needs to be appropriately partitioned.

End users don't need to see technical discussions of bugs. These don't belong on a -users list. They do need an opportunity to provide feedback on feature requests, etc. and these should be discussed on the -users list.

Also a few bugs really should be hidden from the public. Security or other sensitive issues ought to be discussed behind closed doors among the core deveopers. These should then be discussed publically AFTER fixes are available in release versions. However, this should only be the case where public discussion can put the project at risk (security exploits, patent search results, etc).

Re:+1 Transparency

[ushering05401]

No bug should ever be kept from the public.

If there is a critical flaw in one of my public facing systems and the maintainers send out a blast informing me of a zero-day security flaw I can evaluate the situation, consider triage through modifying my local security measures, or simply pull the plug.

It may be a PITA, but finding out that one of my servers was running around naked on the internet while the maintainers of a core product remained silent would be worse.

Re:+1 Transparency

[Tolkien]

Keep in mind that the end-user will not be exposed to those internal discussions, although they take place in public, open forums.

Huh? If they're public and open, the end use can see them. What are you talking about?

My emphasis.

Wait, you got modded +5 insightful for that? Let me try!

Re:+1 Transparency

[Anonymous Coward]

WARNING! There is a remotely exploitable bug in the software you are running on your server! It just hasn't been found, or maybe it has just hasn't been revealed to you or the developers!

Cheers!

Re:+1 Transparency

[einhverfr]

Were it that simple. In practice, I think the following practices are best for security issues:

1) Within 1 week contact the individual that reported the bug and provide a timeline that a fix will be in place.
2) Within a month, unless there are mitigating factors, there needs to be a fix available, security advisories filed, etc.
3) 2 weeks after the initial patch, there needs to be a full disclosure email describng in detail the original issue as well as how to exploit it.

For most security bugs, though, I shoot for initial confirmation and estimation within 1-2 days, and a patch within a week (a simple oversight could be corrected within that first day, but sometimes we need to think through conceptual problems). The 7/30 day expectation gives some slack and avoids problems if something turns out to require deeper changes than expected.

This is based on the fact that one generally finds more robust patches when people aren't working under pressure to get something fixed within the day, and can think through it.

Look, if the person who makes the report feels we aren't being responsive, they can issue their own security advisory. Our policy is aimed at trying to ensure that everyone is on the same page and coordinated moving forward so that people are not at more risk than normal.

The last thing one wants to do is issue a statement like:

"Warning: We have discovered an arbitrary code execution vulnerability in the login screen. It can be exploited by the following method.... We are working on a fix." That serves nobody except the bad guys.

However there is a second case for some closed-door development. A few years ago, some PostgreSQL developers discovered a patent that IBM held over a caching mechanism that Pg used. So they replaced the caching mechanism before publicizing the problem. If you go around saying "Our software may infringe on a patent and may pose liability issues for the user" that isn't good either because now every user might be guilty of WILLFUL infringment including treble damages.

Beyond those sorts of cases though, I agree with you. There are some LIMITED exceptions to the transparency rule, but they need to be kept as limited as possible.

Re:+1 Transparency

[Anonymous Coward]

Keep the transparency. What gripes the fuck out of me is the dumbing down of an open source project to unusable.
Gnome has been the leader in dumbed down software. I'm not surprised they're getting criticized on this.

Since the geektard fanboi's hate anyone who points out guhnomes many flaws I'm going AC.

Where the hell is the box to type a file path? What did you DO to firefox? Why does my mail work poorly with Thunderbird? I'm sure you won't answer. You never have.

The real lesson

[BadAnalogyGuy]

The real lesson here is that not all developers are good.

Open Source means that anyone can make changes to code. It doesn't mean that they should.

Re:The real lesson

[nicodoggie]

Yes, this is true. The point is, even companies who create software and don't release source code have pieces of shit developers as well.

A benefit of OSS is that the True Masters of Computer Programming who may be interested in a project but not yet a part of it can view the code and submit a patch (scrutinized by a group of his peers), and close the reported bug.

Sure errors still occur, but I'd be more worried that no bugs were reported for a non-trivial project, because it just means nobody's really given a good look.

Re:The real lesson

[crow]

Open Source means that anyone can submit changes, but in order to be accepted into the code base, the project leaders have to accept the changes, so any well-run open source project has competent developers reviewing all changes. (You're technically correct in saying that anyone can make changes, but it's not terribly relevant unless those changes make it back into the main project.)

Re:The real lesson

[ta bu shi da yu]

Actually, I rather think that you are placing the blame on the wrong set of individuals here.

I work for a closed-source software company, which has some extremely large customers using our product. We were implementing minor/major releases and we incorporated functionality changes to minor releases. This was a problem almost every time, because at least one of our customers was using that feature and relying on it to work the way it worked in the previous patch.

Consequently we stopped adding new functionality into the minor releases.

You'll notice, however, that it's not the developers that caused this issue. No. It was the project and product managers for either a. allowing the functionality change, or b. allowing the functionality change but not realising the sheer impact it would have on the client-base and thus not planning accordingly.

That said, the difference between the company I work for and the Gnome project (after reviewing the ) was that when a regression occured for us we scrambled for a fix within a week, while the Gnome guys say things like "The bug is fixed when it's closed as FIXED.", "Paolo, Manu: Whining does not really help in getting things fixed.
"What's the hold up?" Write the code for it and attach it here." and "Yeah. And the codebase for 2.24 has changed a lot, so the 2.22 code has to be
adapted/changed a bit. Just do it, the code is available. *shrug*"

The last comment was the most infuriating to a lot of people I think. The best response I read in relation to Andre Klepper's "*shrug*" comment was:

This is a little bit alarming. These *shrug*s and the like are not giving me
the feeling of urgency that I normally associate with finding a really big
regression in a stable point release.

I'm sympathetic to a degree, because I work on other projects often criticised
for their bugginess. But even I can't quite imagine letting such a big
regression go unnoticed, to the extent that it not only isn't mentioned in the
release notes, but isn't awarded an OH MY GOD DID WE REALLY RELEASE THAT when
the first reports file in.

I would like to think that this happened because an enthusiastic young
developer built up a brilliant new design, got half-way through implementing
it, then saw it released while unready at an unexpected point -- and the
consequent worry is that the more we hound developers on this, the more we put
them off developing at all. That would be a terrible pity, and I think there
is an appreciation here all around that a modern replacement for the XSMP could
be a great thing. The error seems to be a management one, rather than a
development one.

Maybe it's just a question of expectation and taste. Like a previous poster
here, I used to enjoy the fact that session management was one of the few
things Linux did unambiguously better than other operating systems. Now it
doesn't, at least for Gnome users -- and it was a shock to me to find that
other developers never actually saw it as important in the way that I did. My
world is not exactly torn apart, but it may have been slightly tweaked in a
small corner somewhere. Gosh, maybe my view of that corner of the world was
wrong all along.

In the mean time, I'm running gnome-session 2.22 and gnome-panel 2.22 quite
happily with the rest of Gnome 2.24 on several machines.

Chris

As a fan of open-source for a LONG time, I'm beginning to wonder if it will ever cut it in the business world. I suspect with attitudes like the ones highlighted above that the answer is "no". And that makes me feel very, very sad.

Re:The real lesson

[Anonymous Coward]

Well, most of open source is like that. It's full of eager developers who seek the glory of making software used by millions of people, but shy away from the onerous responsibility of maintaining and supporting it.

When a user complains, it's often taken as a personal insult or a slight on the developer's talents. They feel the need to retaliate with a dismissive or snarky response, and the whole thing erupts into a flame war. Or worse, the issue just stagnates because the developer digs in their heels simply out of spite.

With proprietary software developed in a commercial setting, one is hemmed in by public relations and the expectations of the people paying for the software. You cannot insult customers. That often does some good and forces people to be a little bit more civil and polite, however aggravating the circumstances.

With open source software, you have to find some way (other than putting them on your payroll) of nudging your developers towards civility, or at least encouraging a culture of cooperativeness towards users.

Re:The real lesson

[Anonymous Coward]

Actually I don't see this attitude in all open source projects. Specifically, I hardly ever see this attitude in the Ruby community. This kind of arrogance seems to be a Linux thing.

Re:The real lesson

[ta bu shi da yu]

A "Linux" thing huh? Could you be more vague?

The GNOME project works on a number of platforms, not just Linux, and to be honest they are pretty much the worst offenders.

Re:The real lesson

[Anonymous Coward]

This is not just a problem with open source projects, its a problem with some people when they are in charge of releases. We have same problem in our company: management appoints someone to manage releases, bugs come, person says "I AM NOW YOUR SUPREME BEING AND I WILL NOT BREAK FROM MY ALL HOLY RELEASE SCHEDULE TO FIX MEANIAL EARTHLY BUGS !!!", managements gets rid of him again ...

Obviously because management in open source sitations are not really that customer oriented nobody is likely to get rid of a stubborn release manager who thinks bugs are just things thats there to mess up his release schedule.

Common developer problem

[QuasiEvil]

Seems like a problem I see very commonly with developers:

Dev: "The old thing sucked, so we built this shiny new better thing."

User: "Does it do everything the old one did."

Dev: "Yes! It's just that the applications don't support it yet."

User: "So stuff that I use now stops working?"

Dev: "But our new thing is better. BETTER!(tm)"

User: "So stuff that I use now stops working?"
 
...and on this goes. Suffice to say the user doesn't give a shit about protocols and how sucky the old system was and how awesome the new thing is. He cares about features that did work now suddenly stop, and in his eyes, your new thing
sucks more than the old one, because it doesn't *work*.

Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.

Sadly, many developers never figure this part out.

Re:Common developer problem

[Anonymous Coward]

Good developers don't care. Said user can go back to his C64 and stop complaining. Everyone else can have progress.

Re:Common developer problem

[Razalhague]

It's not progress if nothing works.

Re:Common developer problem

[thsths]

> User: "So stuff that I use now stops working?"

Yep, that is very much my experience with KDE 4.1. So many things stopped working that it is barely usable. Which is fine, expect that version 4.0 was supposed to be the shiny new framework, and 4.1 was promised to be ready for the end user. By sticking labels on it, the developers create expectations in the user base, and the stick is justified if the expectations are not achieved.

Re:Common developer problem

[tecnico.hitos]

Everything must get worse before gets better, its a matter of balance...

...only that sometimes it gets worse and better simultaneously... and stays like that.

I love whole the world
And all it's craziness
boom-de-ah-da, boom-de-ah-da
boom-de-ah-da, boom-de-ah-da

Re:Common developer problem

[pjt33]

Hear, hear. At work I maintain a internal fork of an open source library we use. Not because I enjoy forking: because the guy with write access to the library's repository started a major refactor 18 months ago in trunk and still hasn't finished it; the subset he uses works, but we use some of the more advanced stuff which he hasn't fixed yet. I can't just take a snapshot before the refactor because then I miss loads of bugfixes.

Re:Common developer problem

[Anonymous Coward]

I think if you get developers contributing their time for free it'll be next to if folly to expect them to focus on avoiding immediate problems for users.

Re:Common developer problem

[stevied]

OTOH, if you never exert any pressure on application developers (to add support for the new shiny thing) and end users (to upgrade the applications), you end up supporting horrific APIs for years (*cough* Windows *cough*)

Open source can afford to be a bit more proactive on this front for various reasons. More of the code that runs on open source platforms tend to be open itself, so if necessary it be fixed by a third party. Linked to this is the concept of distributions, which means someone takes responsibility for evaluating the shiny new APIs and integrating patches for the apps if necessary. Last but not least one would hope that the users are slightly more engaged in the technology they are using, and therefore be prepared to put up with small-ish inconveniences in order to see progress made.

Of course, the particular decision we're talking about here does seem to have been a bad one. But it's a failure of judgement, IMO, rather than a failure of the development culture (i.e. the one that allows developers to make technical-aesthetic decisions sometimes, rather than trying to keep the users happy at absolutely any cost, which is of course impossible anyway.)

Re:Common developer problem

[stevied]

But at least you can do that, even if it's not the most desirable option. With commercial software, you'd only get the backported fixes that the vendor decided were important enough (unless you were big enough client to scream and shout very loudly, or buy a $$$ support contract.)

It's always seemed to me that the basic philosophy underlying OSS was one of "the world is imperfect, but if we work together we can push it slowly in the right direction", as opposed to pretending that everything's perfect and then discovering one day that not only is it not, but that you're SOL because you don't have the freedom to do anything about it.

Having said that, expressing a certain amount of exasperation when stupid things are done is also part of engaging authentically in the process :)

Re:Common developer problem

[Anonymous Coward]

Sure and the users don't get that without code refactoring, development and bug fixes would take even longer. I read the bugzilla thread and IMHO, the guy who ripped out the old session code was careless. You see this "works for me" attitude all the time, in some situations that's fine. When you have users depending on the original code, it's not so fine and you'd better damn well make sure you considered BC in your migration strategy.

The golden rule: Developers should avoid making assumptions.

Re:Common developer problem

[Kjella]

It's a bit too simple to paint this as a user/developer problem. It's often equally much a developer/developer problem between the one changing the interface and the ones using the interface. Breaking stuf without depreciation and/or clear version jumps is very bad. Not following up on deprecation warnings is equally bad. Together, they're supposed to work as a team to make sure that the end user never notices. I've certainly met the kind of developers that will not fix their shit until the compile fails or the application crashes and burns. How long this period should be in practise depends on the circumstances.

Re:Common developer problem

[Anonymous Coward]

The sad thing is, often the "users" are the developers who write those other applications. THEY at least should be able to see things will be better.

The new way IS better, and if they change their application, it will work better as well. But the key word here is change, nobody likes it. They get fixated on the fact that their current patterns no longer work, even when there are new patterns for doing it better.

Re:Common developer problem

[causality]

Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.

Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.

I propose we come up with a name or a term for this argument so that it doesn't have to be rewritten verbatim every single time there's an article that even begins to hint at either a usability issue or the expectations of the average end-user. It'd save all of us a lot of typing and would save Slashdot a ton of storage space. You see, it keeps getting raised as an "issue" only it's not getting anywhere; this "issue" never seems to develop its reasoning. The result is that lots of people are speaking about it, only they're all saying the same thing. If this name or term became a common one, perhaps then we can all just acknowledge the reality that developers are not average users and may think differently from average users. Why, one day, it may even be considered so obvious as to not bear repeating! Or at least, not without also suggesting a constructive solution.

I'll add that constructive feedback is one thing and developers often appreciate it, but I don't feel like I have a moral right to actually complain to an open-source developer when I am benefitting from his or her generosity. If I were buying commercial software or hiring the services of a programmer to perform custom work for me, I would then feel like it's reasonable to expect that the result matches my exact specifications. But when a complete stranger has decided to benefit me expecting nothing in return, that is a different situation in my opinion. Like I said, constructive feedback is one thing, but to complain about not even the software itself but the developer and what they should and should not care about or what their priorities should be seems a little out of line to me.

I think too that we forget that much of the technology we now enjoy is the direct result of advances made by those horribly out-of-touch developers (sarcasm) who did care about the underlying architecture and did think of how awesome the comp sci might be. You don't usually do difficult, painstakingly detailed work like that unless you find something creative or expressive in it that pleases you. This creative force is something that should be appreciated and cultivated. I could make a silly play on your post by saying "sadly, many users never figure this part out." When people lack understanding, they lack understanding; that's all. There's really nothing special about this particular "users and developers" issue except that a little mutual understanding would be a significant improvement.

Re:Common developer problem

[Anonymous Coward]

In real life said user goes back to Windows XP SP3.

Progress for users is being able to get what they want done.

Which is why some worms survive - they do not bog the machine down enough to prevent the users from doing what they want to do.

In contrast a major break in backward compatibility (just because of a "Good Developer") does.

Re:Common developer problem

[skyride]

Absolutely spot on. I modded you +1 interesting for that. Now does anyone have any suggestions? Preferably someone who works with the "users" as they would probably come up with something an end-user would better comprehend.

Re:Common developer problem

[Anonymous Coward]

While true, there are times when a rewrite makes more sense. Where the old code layout makes it difficult to extend or improve upon (possibly causing bugs with changes). Security issues for example may require large changes instead of a mere patch. It's really a question of whether the short term sacrifice will actually benifit the project long term. Remember, just because there is a new rewrite doesn't mean support for the older version has to dissapear. It's up to the developers to determine how smooth the transition is (support the older version until the newer rewrite reaches feature set parity).

Re:Common developer problem

[causality]

Absolutely spot on. I modded you +1 interesting for that.

It was a nice thought anyway. I for one am glad to see your username!

Re:Common developer problem

[jonaskoelker]

Last but not least one would hope that the users are slightly more engaged in the technology they are using

I would guess thath the average level of technical savvy is higher in the free-as-in-linux world; however, I dearly hope that the median level is the same as everywhere else (or maybe even lower).

Or rather, I hope for something that would cause that: a mass adoption of Linux.

Aside: "mass" is an exaggeration: I'd be happy with whichever distribution of market share among vendors (and... givers?) that'll make people take Linux seriously as a desktop platform and develop for real standards rather than Microsoft Standards (tm).

Back On Track: I'd rather have the tech-savvy bar set lower: that's what's going to drive the adoption. It's simple, really: people want computers that work. Their definition of work is "I can igure out how to make the computer do what I want". The easier that is perceved to be (let's try and make that match reality), the better looking the (Linux) offer is.

Re:Common developer problem

[David Gerard]

ext4 is perfect. See, here's the spec that says so! That the two most popular desktop distros are horribly fucked by using it is their fault for being crappy, not mine for writing something that doesn't support real-world use. Look, I can prove it.

Re:Common developer problem

[_Sprocket_]

Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.

Sadly, many developers never figure this part out.

The problem is that we NEED someone to care about the underlying architecture. If nobody does, the system fails.

Yeah, sure - most users see computers as magic black boxes. But they wouldn't exist if everyone just sat around looking at a box and wishing for rainbows and unicorns (although you might get some nice books / movies). Someone's got to open the box and figure out what's going to go in to it to make it do the things people will take for granted tomorrow.

The danger is in extremes. Change too much and you have an unusable system that's never functional as it's always in preparation. Change too little and you have no improvement. End users should realize that they, ultimately, benefit from change - for every thing that they couldn't do without today, there's someone who remembers when it didn't exist (mortality and history permitting). But developers must realize that the changes they're implementing are future targets and they need to consider the method that gets people to those targets while the changes are being worked out.

Re:Common developer problem

[Knuckles]

Which popular desktop distros use ext4 by default?

Re:Common developer problem

[Niris]

I see "forking" and I think "spooning." I need to stay off 4chan :(

Re:Common developer problem

[Anonymous Coward]

XP? Seriously? Windows never had session management, probably never will. You're ranting on the wrong story there.

Re:Common developer problem

[lukas84]

It has the application shutdown thingie.

Re:Common developer problem

[fm6]

you end up supporting horrific APIs for years (*cough* Windows *cough*)

Where does this stupid *cough* gag come from? It's really lame.

I agree that the Windows API sucks. But let's be fair: the X Window System API sucks even more and has been around almost as long. The big difference is that there are some decent APIs running on top of X that impose some sanity, whereas Microsoft keeps bungling every new GUI platform it creates.

Re:Common developer problem

[David Gerard]

None yet, but the problem first showed when Ubuntu 9.04 offered it as an install option. "WAY FASTER! W00T!! andalsobuggersyourdesktop." Ted T'so quite correctly stated that ext4 was behaving precisely per spec and the apps' coding was questionable. Unfortunately, this ignored the consideration that those are the apps ext4 would frequently be running underneath. Apps first, system second.

Re:Common developer problem

[Knuckles]

Yeah, but you said that "the two most popular desktop distros are horribly fucked by using it". To say they are "using it" when they offer it as an option is stretching the term a bit far, and they are certainly not "fucked".

Re:Common developer problem

[vadim_t]

Does this, this, and this not solve the problem?

Re:Common developer problem

[causality]

The problem is that we NEED someone to care about the underlying architecture. If nobody does, the system fails.

Yeah, sure - most users see computers as magic black boxes. But they wouldn't exist if everyone just sat around looking at a box and wishing for rainbows and unicorns (although you might get some nice books / movies). Someone's got to open the box and figure out what's going to go in to it to make it do the things people will take for granted tomorrow.

It's for just that reason that I question this mostly unstated assumption that anywhere there is a gap between developers and users, that it is somehow entirely and automatically the job of the developers to bridge that gap. When you are talking about Open Source software that is both free as in speech and free as in beer, there is certainly no moral expectation that this should be the case.

The average users in this scenario are non-contributing beneficiaries. Non-contributing beneficiaries who are demanding instead of helpful are beggars who are trying to be choosers. Here, I'm not talking so much about what is said and done so much as the way it is said and done and the intent behind it. It's one thing to politely ask for a feature or a change because you think it would be great. It's quite another to make judgments about someone's character or their ability to figure something out because their free contribution was not to your liking.

By and large, these users are unwilling to acquire the skills necessary to implement the changes that they demand from the developers and yet some of them are willing to pontificate about how a developer should think. When the GP said "Sadly, many developers never figure this part out", that is a manipulative way of saying "they seem to disagree with me about what should be important." I say that because some things genuinely are "sad" while others are merely differences of opinion and it is intellectually dishonest to conflate the two. The only reason for doing it is to give an undue appearance of superiority to your own viewpoint but if your viewpoint were truly superior, no such tactics would be needed.

Furthermore, this is a difference of opinion not between two equal viewpoints but between a contributor and a non-contributor. Beware the tendency to automatically consider all viewpoints to be equal. It has a certain allure because it can sound noble but there are many times when it just isn't the case.

When you unnecessarily phrase something in a manipulative fashion, subtle though that may be, it has some interesting effects. Most people are not aware enough to understand why or to see this process as it occurs, but what happens is that they instinctively sense that there is a "wrong feeling" to it. Unfortunately many people, even those who can see this happening, lack the strength to just calmly point it out and show by their example that there is another way. They don't know how to experience it without being affected by it because they are externally motivated and it is external ("externally motivated" = "responds to pressure"). So when they sense this "wrong" feeling there is a tendency to either appease it or to fight it, depending on the character of the person. Both are wrong because both are harmful.

Appeasing it is a mistake because it validates the tactic and sends the message that it's acceptable and will obtain the desired results. It also robs the appeaser of much of the joy that could have been found in the creative process by replacing noble service with demeaning servitude, a process that tends to breed resentment. Fighting it results in senseless pissing contests and personal arguments which reinforce the "us against them" mentality, in this case "the interests of developers vs. the interests of users". It also makes sure that your position is no better than that of the other person and so it destroys your ability to lead by example even if you were initially correct. There a

Re:Common developer problem

[bertok]

Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.

Sadly, many developers never figure this part out.

The entire IPv6 standards group never figured this out.

It's buzzword compliant and has features than can only be expressed in scientific notation, but can you get to your favorite websites with it? No, you can't. You can send email with it? No, you can't.

People wonder why only internet engineers get excited about it.

Re:Common developer problem

[David Gerard]

"Use this crashproof file system!" *

"* warning: filesystem will not crash, KDE/GNOME will. Badly."

Like saying "Linux is crashproof!" when X most certainly isn't.

Re:Common developer problem

[David Gerard]

Oh yeah, and full points to Ted. It's just that he could barely accept that not having badly-written user apps run on his lovely file system could constitute a reportable bug.

Re:Common developer problem

[vadim_t]

This is open source development.

The source is there. The projects accept patches. There's no reason to work around crappy code when it can be fixed.

Ted is technically right, AFAIK nowhere in the standard it says that a rename must flush the file being renamed. For all you know this still breaks in Solaris.

Re:Common developer problem

[Knuckles]

Your prone to unfounded exaggerations, aren't you. Nobody advertised it as "use this crashproof file system!". Point me to the screenshot if you have proof to the contrary.

Also, this has already been fixed before Ubuntu 9.04, for one, is even out of alpha.

That's that, but let it be said that your other examples are at least equally inane (hint: stability without a GUI is still a valuable property).

Re:Common developer problem

[Knuckles]

Gah.

1. You're
2. Second link should have been http://git.kernel.org/?p=linux/kernel/git/tytso/ext4.git;a=commitdiff;h=dbc85aa9f11d8c13c15527d43a3def8d7beffdc8

Re:Common developer problem

[stevied]

Back On Track: I'd rather have the tech-savvy bar set lower: that's what's going to drive the adoption. It's simple, really: people want computers that work. Their definition of work is "I can igure out how to make the computer do what I want". The easier that is perceved to be (let's try and make that match reality), the better looking the (Linux) offer is.

Yup, me too. But the openness of the market should make that more plausible, regardless of the occasional dotty upstream decision. The GNOME guys may have messed up here, and Ubuntu copied them, but there's no reason why a downstream netbook vendor, say, had to follow them. Anyone who has to field tech support calls presumably has an incentive to do some usability testing before shipping stuff, and could easily have decided to stick on 8.04 and backport if necessary. Likewise a university or large company with its own IT department..

IOW, people can engage at the level that's appropriate. If you want it to "just work", and someone to kick when it doesn't, buy a box with a support contract. If you want it to work pretty well but also want to have the choice to try the cool new stuff every now and then, and give feedback directly to the developers regarding bugs and future features, something like Ubuntu's going to be more appropriate.

Re:Common developer problem

[David Gerard]

Oh, I have no doubt. I have little reason to trust ZFS either, see other comment ...

Re:Common developer problem

[vadim_t]

Well, if multiple independent vendors take a spec and implement it in a way that break your assumptions, maybe you should reconsider whether your assumptions were correct.

Hence all the comments about sqlite. If you find dealing with the low level API too complicated, use a simpler abstraction.

Re:Common developer problem

[LingNoi]

Yes that's why everything is divided up into

TRUNK and STABLE

This is a simple case of poor release management by numerous people.

Re:Common developer problem

[stevied]

Where does this stupid *cough* gag come from? It's really lame.

Oh, I dunno, I find it less irritating on screen than when it's done IRL ;-)

I agree that the Windows API sucks. But let's be fair: the X Window System API sucks even more and has been around almost as long. The big difference is that there are some decent APIs running on top of X that impose some sanity, whereas Microsoft keeps bungling every new GUI platform it creates.

I don't know that X sucks, per-se, it's just become quite a large pile of layers over the years, the same as Windows. The difference is that the layers in the Windows stack "feel" thicker. Still, I had high hopes for Berlin / Fresco at one point, but that seems to be a dead project now. At least some people are still concerned with tidying up X..

Re:Common developer problem

[stevied]

Sadly with IPv6 it's the only way to do it. There's no way to extend the address space in a compatible manner, because there's no way for an old node to indicate a new node as a destination address. So it's not a question of IPv6 being badly designed, it's a question of whether to transition at all, or stick with an ever-growing stack of increasingly rickety hacks that may eventually fall over (how many layers of NAT does it take before P2P apps like VOIP can't punch their way through? Excuse me if I don't want to find out the hard way.)

Re:Common developer problem

[David Gerard]

I've at no point said he was wrong that the apps are shittily coded. However, he's missing the point that those shitty apps are an important part of what his shiny new file system (the aspiring default) is for. Just because what he's supporting is written by developers with red noses and long floppy shoes doesn't mean there isn't a problem for him to address. As he eventually agreed, in addressing it.

Re:Common developer problem

[fm6]

People do it in real life? I've only ever seen it on TV shows. I mean, it's really hard to cough and say something at the same time. I guess what I should ask is what TV show first thought it was funny. Happy Days, at a guess, the show that invented the very Shark Jumping meme.

Layers have nothing to do with it. A good API provides a simple way to do common things. You should have to construct a complicated GUI framework every time you start writing an application. Neither Windows nor X Window System has an API that acknowledges that.

Re:Common developer problem

[vadim_t]

The source is there. If the code is shitty, then the right thing to do is to make it not shitty, instead of adding shittiness to another piece of software to work around it.

Also, note:
Patch #1: Adds an EXT4 specific ioctl. Meaning the interested application must specifically call this. Obviously no current apps do. Maybe databases and such will use it.
Patch #2 and #3: These only apply "if the filesystem is mounted with data=ordered". This is the default setting, but the user or distribution can change it, so the application can't rely on this being true 100% of the time anyway.

As per the documentation, ext4 has 3 modes to choose from with different tradeoffs between performance and reliability. The default is the middle one.

Re:Common developer problem

[stevied]

It seemed to be fashionable when I was at school. Drove me nuts, mainly because I couldn't do it convincingly ;-)

The core of X was never really designed for writing apps with directly. At the very least it was expected that people use Xt. The question in my mind has always been whether separating widget drawing and window management from basic region handling was efficient enough, and whether it made things too complicated. Here's a thought: given that GTK+ now uses Cairo most places, and Cairo can target DirectFB, how hard would it be to run GNOME or Xfce without X?

Re:Common developer problem

[amorsen]

There's no way to extend the address space in a compatible manner, because there's no way for an old node to indicate a new node as a destination address.

Sure there is. The easiest backwards-compatible option would be to add an optional extra address field to the IP header. NAT gateways would then examine any incoming packets, and if they have that option set, they would pop off the first one and send the packet off to whichever address was named there. For packets without such options, they'd behave as they always did.

*poof* no more address shortage. An additional advantage is that NAT could no longer pretend to be a security tool.

IPv6 is a great leap forward in every way, but I still think there's a 50% chance that a proposal like the one I just made will win.

Re:Common developer problem

[stevied]

It sounds like you're thinking about assigning bigger addresses only to clients, i.e. the ones initiating the connections. That's fine, but at some point we're going to need to assign the new, bigger addresses to servers, and that's a bit of a different issue (and of course with P2P, everybody's a server.) For servers listed in DNS you could I suppose do the reverse of what something like totd does, and return a fake IPv4 address to the old IPv4-only client, but .. yuck.

At some point new code will have to be deployed, and we've done the work on IPv6 now, it's ready to go. I'll concede that if something simpler had been proposed originally, it might have seemed less scary and so been deployed quicker ..

Re:Common developer problem

[grcumb]

Computers, for most of us, exist to accomplish other tasks. The users really don't care about the underlying architecture, or how comp sci awesome it might be, they just care about feature parity when big chunks are replaced.

I propose we come up with a name or a term for this argument so that it doesn't have to be rewritten verbatim every single time there's an article that even begins to hint at either a usability issue or the expectations of the average end-user.

Call it 'Little Red Hen Syndrome', then. The unfortunate truth is that non-participants in FOSS culture are only coincidentally beneficiaries of its largesse.

Actually finding a role for oneself in the process of making Free Software better is at times onerous, awkward and occasionally frustrating. Ironing out differences in perspective and expectation is a task that humanity has never done well, and - surprise surprise - FOSS is no exception.

My personal experience, however, is that, like democracy, it's simply the least terrible of all the alternatives.

An example: I endured online standards flame wars of the 1990s, trying to maintain a calm, rational stance in the face of unreasoning demands made by co-called Web Developers who really thought they could author HTML with the same ease (and tools) as a Word document.

It was ugly at times, an imperfect and agonisingly slow process, but now at last it's conventional wisdom that content and presentation are two separate things. Most web developers working today don't realise just what an effort it took to actually sell people on the approach that's now accepted as axiomatic.

I'll be the last person to say that everyone who doesn't participate in FOSS projects should shut up. Quite the opposite. All I'm suggesting is that if you're going to tell Mama Raguzzi how to cook better pasta, you'd do well to learn a little Italian.

Criticism, discussion, griping and debate all have their place. Learning to formulate one's thoughts in a culturally appropriate manner sure helps make them more palatable and ultimately more useful.

For those who don't know and don't care: You have my sympathy when things don't work out to your satisfaction. But it's simply not realistic for you to expect FOSS to care about you if you don't care about it.

The infinite replicability of binary data makes it possible for everyone to share in the outputs of a few. But it's not rational to expect those bits to take a shape that more perfectly meets your needs unless you help to shape them yourself.

Re:Common developer problem

[martin-boundary]

I propose we come up with a name or a term for this argument so that it doesn't have to be rewritten verbatim every single time

Can I propose "users are lazy"? It pretty much explains everything, if you think about it. And I don't just say that as a developer, either...

Re:Common developer problem

[justinlee37]

Not because I enjoy forking

Don't kid yourself, this is slashdot. You and all the other geeks here would love to do some forking.

Re:Common developer problem

[msclrhd]

Then it is not refactoring. Refactoring should (barring typos and thinkos) keep the functionality identical *with every change that you commit*.

What that guy is doing (and what the Gnome devs are doing with the session management) is essentially a rewrite. These are tricky and potentially dangerous, but can be beneficial in the long run. However, these should always be done on a branch and should be tested. Regressions are likely to happen with this type of work.

I am surprised that the reviewers for the Gnome project allowed unimplemented code to go in, especially for major functionality.

Re:Common developer problem

[msclrhd]

The new Gnome DBUS session management system may be better than the X protocol, but:

1. will other session managers adopt the new protocol (KDE, Xfce, X11)?
2. what if a user wants to use an older version of a program that only supports the older protocol?
3. will application writers need to support both protocols? (answer: yes)
4. applications supporting both protocols will need to abstract it - how easy is this to do?
5. what if an application refuses to use the new protocol (not standardised, not stable, not enough devs/testers to manage this)?
6. what if the protocol changes on standardisation and there are applications using it? (this may or may not be related to 5, depending on how the new protocol is designed)
7. is it possible to support newer versions of the protocol with clients that support older versions, and the other way around? (otherwise the protocol cannot change to support new functionality and features - there is a reason COM was designed the way it was)
8. what if newer applications adopt the Gnome protocol and remove the X protocol? (answer: the app will not save sessions and may crash on other systems)
9. what if the application is built without the Gnome protocol support?
10. what if I don't want DBUS on my system? (yes, I know this will break a lot of things now, but it is a valid question)

What this comes to is that (1) writing APIs and protocols is hard; (2) changing APIs and protocols is harder. The more clients of those APIs and protocols you have, the harder it is to change. There is a reason why X11 and the Win32 API are the way they are and why they have evolved the way they have.

Was the protocol spec actually reviewed, or was it a "lets push this change regardless"?

Was there a migration strategy planned?

Were upstream clients of Gnome informed of this proposed change (applications, distributions, etc) so they could have their input?

Re:Common developer problem

[Lennie]

A lot of the time users don't have to pay for upgrades/updates, that also helps a great deal

Re:Common developer problem

[amorsen]

DNS would need a new address type instead of A. It would contain a list of IPv4 addresses. Something like 1.2.3.4:5.6.7.8:9.10.11.12. Old clients would only look up A, and so they wouldn't work.

It wouldn't be a big problem though. There are many many clients for every server, and people who need P2P would be eager to upgrade.

Re:Common developer problem

[krunk7]

Seems like a problem I see very commonly with developers:

Just to chime in as a developer. Here's how the conversation too frequently sounds from my perspective.

Dev: "Due to ever improving changes in hardware capabilities and the demands of the field, we had to refactor several of our libraries. Though we tried to maintain backwards compatibility as much as possible, in some cases we could not."

User: "Does it do everything the old one did?"

Dev: "Yes, and more. You can now x, y, z which was not possible in previous versions."

User: "So, does the stuff I use now stop working?"

Dev: "Some of the API's changed, so will need updating. We tried to provide verbose warnings that provide an API reference and a suggestion on how to update to the new API."

User: "Oh no! The sky is falling, we'll never be able to update our code. This is a momentous task, we're stuck with legacy software for the rest of our lives! How could you do this!? How?? HOW???" ....

8 years later. User and his group has pushed the legacy version of their implementation to its extremes. Support for the old version was dropped and the user's last bit of ancient hardware that could still run their implementation has died. They are now forced to not only upate to the next most recent transitional version, but also to the several versions that came afterwards possibly compounding the upgrade cycle.

The group insists that the project is an impossibility, but finally assign a developer to the task. They never actually consulted a developer in the first place, the managers just *knew* their code base was so advanced and complex that it would take years to update.

The developer begans collaborating with your support team. Three weeks later their software is updated and working with the most recent version. Many are left wondering why they didn't do this in the first place.

Before discounting this. This story was fashioned after a real life example. I kid you not, the lab group paid more money to the managers and researchers (users) in meetings about how difficult it would be and how nigh impossible to find the funds to do it would be than they did in actual salary to me to fix it.

Re:Common developer problem

[MadKeithV]

Yeah but it doesn't work much better than the last release.

It is a problem... we need tracker moderation

[zenyu]

When you run an open to post bug tracker you are inundated with idiots who think a bug tracker is a discussion forum as well outright spambots. Some of the "me too" and "I think this is a major bug" posts could be addressed with a "me too" button and counter in the tracker. But..

I have a modest proposal for what we really need:
    1/ cold hard cash
    2/ nothing appears in the publicly visible tracker until approved by a moderator

The way this would work is when you file a ticket your credit card should have $50 deducted and the ticket hidden from view until it has been approved, if approved you should get $40 back. So if you report a crash without the backtrace or even a description what you were doing when it happened you are out $50. After paying the CC fees any 'profit' could be burned in trashcans to provide heat for the homeless, just so the moderator can not be accused of being unfair for the cash. Similar fees could be applied to ticket comments, say starting at $10 per inane comment and escalating to $100 for repeat offenders. None of these comments would ever have to make it out to the publicly visible face of the tracker, but there are plenty of people who would still keep posting at $100 a pop just to annoy the devs. Burning thousands of dollars in small bills could warm the hands of many a homeless man, and scaled up to a large number of OSS apps would help keep inflation under control.

To the humor impaired: Ok, this is tongue in cheek. My point is that once a project grows past its first few thousand users a public issue tracker becomes a liability. Real bug reports get lost in the constant barrage of junk tickets, but you can't even close those junk tickets because then you have to deal with some luser with a bee in their bonnet.

Re:It is a problem... we need tracker moderation

[stevied]

I seem to recall Sun used to charge customers for reporting bugs that it later decided weren't. My memory is not what it once was, however :)

The meandering nature of discussions on bugs.launchpad.net has been bothering me too, recently. Maybe a simple Slashdot-style moderation system is a solution? I think LP already has a "me too"-type button / link, maybe there should also be a way for admins to convert users' otherwise content-free "me too" comments into simple votes for fixing the bug, which would unclutter the discussion without the losing genuinely valuable info (how many people are affected) and, hopefully, without people feeling they couldn't engage with the developers (maybe list the users who have voted)..

Re:It is a problem... we need tracker moderation

[Anonymous Coward]

but you can't even close those junk tickets because then you have to deal with some luser with a bee in their bonnet.

Maybe you should pay the botnet user so that you can close the ticket. Maybe 10$, I don't know. He will give it back to you if the ticket was really junk!

btw, how much are those cc fees? never really thought about that.

Re:It is a problem... we need tracker moderation

[TheSpoom]

Doesn't Gnome already require a trusted user to confirm bugs in their tracker before anything is done with them?

I know that was the case with one that I discovered after talking with some Gnome devs on IRC (and the guy I was talking with immediately confirmed it; for the curious, it was a bug in Evolution).

Re:It is a problem... we need tracker moderation

[bkor]

No, that is not true.

Only some users can confirm bugs, I assume you think it implies more than it is in practice.

Re:It is a problem... we need tracker moderation

[Kjella]

Regarding becoming a discussion forum, in my experience it's a sign of lacking other ways to give some design input. In the commercial world, if you bother to put together some notes on what problem you're trying to solve, how the solution is today and how it could be improved, what it means for you and how it could help the product in general. then it's usually well appriciated. That is because there's someone sitting on the vendor side guessing what the customers want and need, who appriciate you taking some of your time to give them a few pointers that might result in the vendor making a more successful product. Win-win.

Many open source projects don't seem to actually take any input from their users. The developers don't frequest the user boards, and if you ventured into the development area you're usually either met with indifference, clear feedback that if you want it then write it yourself or that if you really want it that badly then cough up some cash for custom development. Great, but you aren't that involved and just thought you could contribute something positive but instead it's taken as something negative and whining for free pet features. There's nothing in it for them, so no win-win.

It's a world of difference between coming up with the idea AND 500$ in custom development compared to selling them on the idea that "implement this, and you can sell 25 more copies at 20$/pop". So where do you meet some developers without going through this? Well, you start a bug which amounts to the software "not working" by not doing what you want and make it into some kind of quasi design-bug. It sorta puts the scene that this is something you think should have been working, not some "wouldn't it be nice if we could...." enhancement. It's not how it's supposed to be, but it's a very human thing to do.

Re:It is a problem... we need tracker moderation

[TheSunborn]

Microsoft does that too. Or atleast did 5 years ago when I tried to report a bug to them.

Re:It is a problem... we need tracker moderation

[Anonymous Coward]

1/ cold hard cash

How would that work?

2\nothing appears in the publicly visible tracker until approved by a moderator

That is a very efficient way to flood the bug tracker service with redundant bug reports as well as stiffling the amount of work that the community (i.e., non-project people) do in areas such as error tracking, support and *ghasp* even posting patches.

Re:It is a problem... we need tracker moderation

[blackest_k]

The nice thing about a public bug tracker is that many problems have been raised and solved often without changing a single line of code. As a simple example my ethernet card was showing up as eth8 and not eth0 by use of google and finding a bug report i found the reason was due to a udev rule and a particular file which i then edited to get eth0 back. There was no need to go any further.

I found another feature/bug in open office writer today I wanted a block of text in title case and found open office gives the option of lowercase or uppercase and applying a character effect to the selected text all good apart from i just wanted to get title case and paste the text into kompozer however as the title case is just an effect applied to the underlying text so the title case effect is stripped away when you paste as plain text into another application (incidently gedit has a plugin which does title case properly).

komposer in ubuntu intrepid crashes when submenu's are accessed, but there is a repository recently set up with a working version of kompozer that works with hardy intrepid or jaunty (why do I know because of the bug tracker).

3 reasonably simple examples which show that bug tracker does work quite well in the eyes of the public. For devs I can imagine how much it sucks to get the same old questions and incomplete bug reports that are useless. However dev's shouldn't be looking at unconfirmed bugs and there should be an intermediate layer of experienced users and interested parties who can confirm deny and hopefully reproduce the bug on demand and then they can raise the problem with the people coding the project once its shown to be valid.

Re:It is a problem... we need tracker moderation

[zenyu]

1/ cold hard cash

How would that work?

Credit card, bank transfer, and paypal would all work. There are plenty of ways to transfer money these days.

2\nothing appears in the publicly visible tracker until approved by a moderator

That is a very efficient way to flood the bug tracker service with redundant bug reports as well as stiffling the amount of work that the community (i.e., non-project people) do in areas such as error tracking, support and *ghasp* even posting patches.

The worry of course is whether it would be stifling in any way, and why it was a tounge-in-cheek proposal. I don't really know if it would stifle the amount of work that the community could do. I know there would be fewer duplicate tickets, in my experience there are generally about a couple dozen tickets created for any long lived bug, maybe a quarter remain open even after the bug has been fixed because they were never flagged as duplicates. Also hundreds or thousands of incoherent tickets mean that someone experiencing a problem has to wade through more useless search results before either finding the appropriate ticket or finding that a report is in order. Lots of bad tickets also mean less time to look at patches, so people producing patches produce fewer of them.

I have a nice coherent bug report sitting in the gcc bugtracker over a year now, I'd happily pay $100 just to have one of the devs triage it. Instead it is lost in piles of cr*p. The question is how much do old happy hackers like me contribute to a project vs. a can't afford pizza school-kids? When you make my life as a bug reporter easier you make the lots-of-time-no-money-college-kid's life harder. Is that worth it to make the lives of the more dedicated contributors easier as well? I would assume it depends on the project.

Re:MOD ARTICLE: FUD

[stevied]

OK, I'll bite.

I don't think the submitter was knocking OSS, or advocating commercial software as an alternative. I think s/he was genuinely interesting in figuring out what went wrong here, what to do about it, and how to handle the increasingly forum-y threads that turn up on bug trackers these days (particularly on launchpad.)

Adapt Policy in the Open

[thethibs]

"Bugs in software are nothing new, but when they're discussed in the open, how do open source projects adapt policy?

Policy adaptation is a care-requiring activity, especially if discussion in the open is involved. Closed projects may get away with customer defenestration, but open source projects are more susceptible to their developer community and enthusiastic users. How a project would adapt policy should be given a great deal of thought and dialog to ensure no one is left out of the loop.

I hate to say it

[TheSpoom]

But things like this are why people still trust Windows more than Linux; at least they won't randomly lose major features after an upgrade.

Re:I hate to say it

[JustShootMe]

Not entirely true. I just switched back to Linux from windows for that very reason. After an upgrade, I lost networking for no reason. Took several reboots of boh the laptop and the wireless router to get it back.

At least with Linux you know the regression was likely intentional. Stupid, but intentional. The Windows folk just don't know what they're doing.

Re:I hate to say it

[Bazman]

Yeah, like being able to load old versions of their Office files. Oh, wait...

Re:I hate to say it

[Anonymous Coward]

At least with Linux you know the regression was likely intentional. Stupid, but intentional

Actually in Linux I've had the experience of having lots of stuff break by an unintentional mistake of a developer or package maintainer. In fact, that's the most common problem I ever encounter.

Yes, there's lots of intentional breakage -- such and such a kernel API won't work when you upgrade your kernel -- fine, if you've got programming knowledge that's usually an easy one to work around. But do you think for example, that Debian meant to weaken the crypto in ssh by initializing memory to zero? This is one high profile case, but I run into smaller, less severe ones working with Linux all the time.

And actually, FWIW, Linux seems to have a worse track record at this than say, the *BSDs.

Re:I hate to say it

[BikeHelmet]

Heh... funny, but I have the opposite.

It seems like every open source project eventually swerves off the road and into a ditch.

-OpenOffice v3.0 (fails to register extensions on many Windows systems; no file extension dialog)
-Deluge Bit Torrent (Options to start in a paused state removed; blocklists now load after torrents start and connect to seeds/peers)
-CVS (I've never used it, but why do you think SVN and GIT now exist?)
-Gnome (Kills apps instantly. I don't mind, to be honest. I even use this feature to my WinXP box - although it waits 5 secs before killing them off.)
-GIMP (Now out of the ditch, but around v2.2, "stable" meant it ran at least 2 minutes without crashing, and 75% of the plugins can be used without an instant-crash.)
-Firefox v1.5 (Hehe... I still rememeber the leaks and crashes. And the swallowing my profile whole, and spitting out an empty one. And the erasing 60% of my bookmarks for a laugh.)

Re:I hate to say it

[Anonymous Coward]

That works fine, so I have no idea what you're talking about.

Re:I hate to say it

[vadim_t]

OpenOffice, from what I heard of it, isn't really as much an open source app as an "opened closed source" one. I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something. And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please. Outside contributors may find that something they spent a month working on is now useless, because core decided to rewrite some internal subsystem with no announcements and no discussions.

I don't think you can really use the second case to illustrate the quality of OSS development, because this sort of project management rarely differs much from closed source approaches. They might accept your patch for fixing a memory leak, but if they want Java to be required for it to work, then they WILL get their way, even if absolutely everybody else disagrees. What seems to result is that the project goes in the same direction it would have had if it remained closed, except outsiders are allowed to make minor improvements.

CVS seems a bad example, too. CVS is ancient in its design, and source control programs aren't things that can radically change their designs, because projects put processes around tools like that, and it all would break if CVS suddenly turned into Git one day. CVS' problem isn't that it has a bad development model, but that it implements an ancient and very limited design. The better systems were made after thinking on the design mistakes and limitations of CVS.

You can try Subversion instead, which is more or less "CVS done right", and removes some very annoying flaws in CVS. But it still follows the same fundamental model of revision control, so things can still be done a lot better, and it's not a drop-in replacement for CVS.

CVS is a legacy project, sort of like a Gopher browser. It can't be made much better because it's an implementation of an obsolete design, about the only thing to do with it is to maintain it.

Re:I hate to say it

[comm2k]

But things like this are why people still trust Windows more than Linux; at least they won't randomly lose major features after an upgrade.

Like file-sharing via firewire (1394) just vanished in Vista - though it was available in XP?

Re:I hate to say it

[Chuck Chunder]

It's just not true though.

I've had wireless network drivers stop working after a windows update installed new ones and only got them working again by uninstalling them and installing an older version.

Just this week I was using Visio to reverse engineer an old DB schema but a security update in one of the office service packs stopped the functionality working. For a while you had to roll back the update to get it working. Then there was a hotfix you could get but had to contact MS support for. By the time I was hit by it there was a generally available fix for it.

Perhaps those aren't the same sort of features as session management which effects everyone but proprietary software isn't immune to the general problem.

Re:I hate to say it

[Anonymous Coward]

> I see mostly two ways development can happen: community style, like the Linux kernel, where everybody can contribute something.

Just try to get a major change into the Linux scheduler, the memory management, the file systems or other critical parts Linus cares about. And maybe talk to Andrea Arcangeli how he felt when his memory manager was thrown out, or to Con Colivas about his scheduler.

> And core-driven, where the development team sort of throws a bone by allowing people to see the code and submit patches, but does development however they please.

Linus also does however he pleases with HIS kernel. There is no chance in hell anyone could get code into it doesn't please him. He himself sees his role as a "benevolant dictator". It is a good thing that someone is taking this responsibility. No open source projects would have gotten anywhere if anyone could just dump their code into the repositories.

There should be one big rule for all of this: "The ones handling the bug reports and fixing the bugs gets to call the shots". It's really easy if you think about it.

Re:I hate to say it

[Raenex]

At least with Linux you know the regression was likely intentional. Stupid, but intentional. The Windows folk just don't know what they're doing.

That's a bunch of crap. I've run both Windows and Linux and they both have their share of bugs. I have experienced clean upgrades with both, and broken upgrades with both. Software is complex, and so is the mix of hardware that operating systems have to support.

Incentive

[ishmalius]

What is the incentive for unpaid developers to abandon their private lives to go into crunch mode developing something for some(thankless)one else? A thousand "me too" on a bug tracker or a million "+1"s have yet to purchase a cup of coffee. "Market share" and "exposure" have little value to encourage altruism in project members. But endless bitching has enormous power to discourage it.

A smart member of this project would neither post to nor reply to that bugtracker thread.

But that's only because this discussion is missing the point. The value of user-developer communication is for the fostering of ideas efforts for everyone's benefit. It is -not- a mob government to drive the project's direction, nor is it a help desk.

Re:Incentive

[JustShootMe]

No, you're missing the point. Yes, that is one value. But the popularity of an open source project is directly tied to its influence. If there are too many regressions like this which are incompetently handled, people will end up saying "fuck it" - and either fork the project or move off to something else entirely. Just because you volunteer your time doesn't mean you don't handle it professionally - these things reflect on you when it's time for the rubber to meet the road and you need to get paid sometime down the line. If you're unprofessional and handle these things stupidly, any decent employer will start to look a little askance at your ability to handle crises in a competent and confident manner.

Just because you're not getting paid for it doesn't mean your actions as a project developer/leader don't reflect on you professionally.

I admit to having screwed this up myself with a project I maintain - something I'm trying hard to rectify as we speak.

Re:Incentive

[ishmalius]

I don't mean ignore users, nor put out bad code.

Actually, it looks like the people working on the session code are doing an excellent job, and doing the best they can to create a quality package. It just appears that, unfortunately, either Ubuntu or Gnome made a release cut in the midst of the session package's gradual migration from one IPC mechanism to another. The session code itself is not an issue, as far as I can tell. So, where was the problem generated, and who gets blamed? I see 3 points of contact, with 2 or 3 different organizations. Even with everyone doing the right thing, mistakes can happen.

My only issue with the posting is the idea that the user-developer relationship is a one-way thing, with users driving the development, and receiving free labor in return. That is not how it is (or should) work.

Open source is a collaboration between users and developers with mutual respect among all. They share ideas, goals, designs, etc, for the benefit of everyone. Developers -need- user feedback, SME info, the "second pair of eyes," etc. This frees the developer from the narrow focus on the work they are doing. Otherwise the package is a hothouse flower which is useful to nobody.

And it is a fair relationship, because a developer of one package is a user of all others.

Re:Incentive

[6Yankee]

I admit to having screwed this up myself with a project I maintain - something I'm trying hard to rectify as we speak.

With this sort of honesty and self-awareness from the maintainer, I'd feel a lot more comfortable about using the product (and contributing to it, if I were able).

Re:Thank goodness...

[JustShootMe]

Flamebait? No, not flamebait. Allow me to clarify.

Fedora decided that they were going to ship KDE 4 before it was ready. I unfortunately decided to upgrade to Fedora 10. Half the features weren't there, it crashed randomly and had unexpected behaviors, and it was just unusable. I was pretty unhappy with the whole situation. Kmail still has a few regressions in it, the "system settings" is pretty unpolished, and they are still nowhere near the level of 3.5, even on 4.2. 4.2 has been the first release that's even remotely usable.

This gnome thing is just a small (incompetently handled) change in architecture that'll be fairly easily fixed. The KDE clusterfuck was on an entirely different level.

And I like KDE. I used to be a KDE devel. I just am very unhappy with how both they and Fedora handled it. Talk about a regression...

But that is a different related issue

[einhverfr]

Which is change management. When and how do you make needed changes to code? Like it or not, most developers have absolutely NO skills in actually managing a project of this sort, and have none of the related process/management skills. Some do, but most don't.

What most projects REALLY need is a small committee which handles policy changes. Do we want to refactor in the middle of a stable branch? What are the policies involved in releases, etc, and actually enforcing this sort of thing. Then you have a much larger group of people who do development and get pushback from this management committee when they don't play by the rules. The management committee should have the power to grant and revoke commit access to the source repositories. And really that access needs to be earned.

A third, related question is support lifecycle. How many older versions do you support?

If all of the above are well managed the developers can build better products, but you can still properly manage legacy users and general use of the software.

There is nothing magical about open source

[westlake]

But at least you can do that, even if it's not the most desirable option.

You can do it if you have the time and resources needed for the job.

In that respect, "software freedom" is rather like "freedom of the press," something to be celebrated on the Fourth of July.

It's practical significance is for those in the trade - and even there it can be more symbolic than real.

Re:There is nothing magical about open source

[stevied]

It's practical significance is for those in the trade - and even there it can be more symbolic than real.

Agreed - with the first part anyway. But even then it's hopefully still a win for end-users in the long run: the availability of the OSS code base should reduce the barriers to entry into the various markets that can use it, which should mean competition. Nobody expects Joe User to be touching the source to the programs he runs, but if the company he buys his mobile / netbook / home router / tech support contract from can, they can customize their offering to better suit his needs, and hopefully make him happier.

I think the advantages are now becoming obviously real. Small example: My eee 701 runs Asus's hacked-up Xandros, which in a way sucks because they're not doing stuff like pushing security updates, but, because it has Debian not far away in its geneology, it makes it easier for people to get Ubuntu derivatives on it. Larger example: Dell kit running Ubuntu. I don't know how their installs differ from the vanilla distro, but the option is clearly open for them to modify the interface if they think it would help their customers, or to maintain a fork if they want to protect them from the occasional daft upstream decision.

It's arguably a bit messy if, say, every netbook vendor ships their own distro, but at the end of the day each fork is going to be fairly closely related, making switching from one the other easier, and anyway market forces will encourage merging changes upstream and / or lateral transfer.

IT is very odd. We expect a choice of food products in the supermarket, we expect a choice of car retailers on our local industrial estate, but most people have quite happily accepted zero choice in operating systems for at least a decade. Sure, we'll need interoperability to make the market work, but that's proven to be do-able in other domains (the third-party wiper blades, light bulbs, tyres, exhaust and audio equipment in my car all work just fine.)

I expect change to continue gradually creeping up from traditional embedded markets (home routers, mobiles) to netbooks and then beyond. When people twig that the OS on their netbook would also quite happily run their PC or laptop, they might start to think twice about paying the MS tax..

Re:There is nothing magical about open source

[grcumb]

In that respect, "software freedom" is rather like "freedom of the press," something to be celebrated on the Fourth of July.

It's practical significance is for those in the trade - and even there it can be more symbolic than real.

I was tempted to say that your attitude toward press freedom is telling, but then I decided to replace the word 'symbolic' above with 'potential'.

Ultimately, I think I can accept your premise, if not your interpretation. But then again, I've contributed to more than a couple of FOSS projects, and I write a weekly IT column, precisely because I think there's a place for both every day in the year.

I work in the developing world, and am an aggressive user and promoter of FOSS mostly because of the robustness of the system (if not in all particulars). Speaking from experience, the virtues of an open system have direct, practical applications in my day-to-day work.

Call me lucky, or call me someone who's decided to actually use those things that you insist exist mostly in potentio, but I've actually had FOSS developers travel thousands of miles to see how they can help here.

You can call me lucky if you like, but I don't think I'd agree. I can certainly accept that my example is not common. But it would be more accurate to say that I'm simply one person who's decided that FOSS culture is there to be exploited, and I've been rewarded significantly for my efforts, and those of others as well.

Bottom line: The strengths that you seem to pooh-pooh are real; and they have very real rewards. If you invest in them.

Re:There is nothing magical about open source

[Kjella]

In that respect, "software freedom" is rather like "freedom of the press," something to be celebrated on the Fourth of July.

It's practical significance is for those in the trade - and even there it can be more symbolic than real.

I think if you were to live in a country that did not have a free press, you'd miss it. Particularly since it's almost certainly go with restrictions on free speech. Many of the rights in the bill of rights apply to some specific class, like "criminal suspect" and if you aren't in it you probably never invoked the 4th, 5th, 6th or 8th amendment. If you're not a gun owner, the 2nd amendment doesn't apply directly to you. I don't know anyone that's ever invoked the 3rd amendment in the 21st century. It's a matter of cause and effect, because it's in the constitution the government doesn't violate the constitution thus people don't need to invoke the constitution. It may give you the illusion that it's not necessary, but then you're mistakenly assuming the government's behavior would be the same without it.

Tell me more

[westlake]

After an upgrade, I lost networking for no reason. Took several reboots of both the laptop and the wireless router to get it back.

There is always a reason.

You talk about an upgrade. What were you upgrading?

Hardware? Software? Third-party driver?

If the re-booting solves the problem it strikes me that the OS is doing it's job on start-up. Unloading the trash. Resolving conflicts. Working towards a clean launch.

Session management

[ultrabot]

A major regression in the Gnome project's session manager has seen some major distributions choose to refuse to follow the update rather than drop a major feature.

I think losing that "feature" is a feature in itself.

I'm currently using xfce, and the fact that the session manager thinks it works annoys me quite a bit. I have in fact turned it off, but it still chooses to open a bunch of firefox sessions before wlan is up (and NetworkManager is querying the password in the background).

Another useful "feature" of session management is opening up 17 terminals on bootup. This feature just needs to go. I'm not a big fan of Gnome, but they got this thing right ;-).

Re:Session management

[stevied]

I seem to recall having to delete some files from somewhere after disabling session saving in Xfce (~/.cache/sessions maybe?) Either that or closing everything and quitting to save an empty session first, and then disabling it ;-)

[OT-ish] ext4

[stevied]

I'd rather have ext4 than XFS!

It was just one of those nasty intersections between real-world usage patterns and and unexpected consequences of an intended feature (isn't the whole point of extent-based filesystems that we can do stuff like delayed allocation?) Sadly, I guess Canonical can't yet afford to pay to have hundreds of users sitting in labs typing randomly at PCs like MS can.. but OTOH, isn't a beta release a good substitute?

And let's not forget, Ted produced patches PDQ. He had a bit of moan at the same time, but he did produce patches. That ranks pretty low on the prima-donna scale in my book :-)

Re:[OT-ish] ext4

[David Gerard]

Fair enough :-)

just wait it out

[pizzap]

I'm going without session management for about 6 month now and I really didn't notice. Gnome session 'management' has always been broken, at least for some years imho.

Isn't that how it goes? Some things break, more get better. Next ubuntu release is just around the corner anyways.

Do you remember pulse audio, upgrading to 64bit, how long it took for utf8 to actually work out of the box, or this one issue with redhat and kgcc?
There is no easy way, progress always creates problems.