[JoshTriplett]

I find it wryly amusing to see the entire GNOME 1 -> GNOME 2 debacle repeated so accurately. GNOME 2 eliminated a huge pile of configuration and tweakability that had accreted over the years, and produced an environment designed for user-friendliness even at the expense of some power-user configurations. It took a few releases to sort out (2.0 proved quite painful), but by GNOME 2.4 or so the environment had become far more pleasant than GNOME 1.

If the GNOME 2 -> GNOME 3 debate has produced more vitriol by volume, I'd say that just reflects GNOME 2 having a much larger user community than GNOME 1 ever did.

[joe_the_user]

Sure, but the thing with Gnome 3 is that Gnome made the decision that they would piggy-big a "new, modern interface" onto their overall graphic environment (Gnome 1 and Gnome 2 used the paradigm more or less popularized by Windows 95).

Sure, Microsoft and Apple feel like they have to shove a new load of, uh, cr-p onto us on a regular basis and have enough resources to maybe make that work. But Gnome just didn't have the same marketing positioning.

I'm all for modernizing interfaces. But it seems like either Gnome choosing one or Ubuntu choose one and then these being pushed on us isn't really a good way (or an effective way). Because "modern" mean "opinionated" and open source probably won't easily adopt opinionated approach.

[makmanalp]

Same with KDE3->KDE4. They released 4.0, saying it was a beta. Guess what, if you call it 4.0 and do a release announcement, people will get it no matter what you say. And then they'll judge based on your pre-release status, calling your software crap. It's the lesson no one learns.

[sho_hn]

Let's be clear though, it went down quite similarly with Mac OS X: 10.0 was quite troublesome and not exactly well-received. Look what happened later. Ditto Vista and Win 7. The pattern is not limited to FOSS.

I think the lesson here is that the circumstances at times compel platform vendors like KDE and Gnome to make these big next-gen releases, and the market compels them to do them before they're quite ready for end-user primetime, because the alternative is a serious loss of momentum, e.g. in the third-party space that is waiting for that release. And this is likely even more true in the FOSS space, because you're not just bleeding third-party interest by not shipping, but also developer recruitment.

It's a balancing act. Looking back, I don't think we found quite the right balance with KDE 4.0. But realistically, shipping 4.0 only when it had achieved the quality level, of, say KDE 4.5 just wasn't going to happen, either. Because if we hadn't shipped at some point, we'd might not have gotten the influx of contributors and early adopter feedback that we needed to make 4.5 happen.

Really, people are being presumptuous by saying these things happen carelessly. The reality is that there are pressures pulling you into different directions. You sometimes make bad calls under pressure. At other times you make the right call but get to chose between multiple options that each have their own downside attached.

[joe_the_user]

What prevents a "loudly trumpet Beta"? Say "this is our beta, try it, critique it but don't count on it being perfect"

Call it "4.00001" or "3.9999". It seems to me that you could get people's attention and so get test users while still trumpeting the software's "not-completely-finished-ness".

[sho_hn]

Getting people's attention with a beta is unfortunately pretty hard. Two things:

a) It's not all about beta testing. A big thing is developer recruitment. The demographics among FOSS developers ensure a relatively high amount of turnover: Many of them are at an age where their life and/or job situation is likely to change within two-three years, causing them to move on. A steady influx of new talent is needed to keep the show on the road.

At the same time, a project that isn't releasing is less attractive to contributors for a variety of reasons: The time it will take for your handiwork to be delivered into user's hands, the level of information circulating about contribution opportunities (i.e. "what does this even do that I might want to hack on"), et cetera. It's also still true that a lot of FOSS contribution is itch-driven: You start contributing because what you're using isn't doing quite what you need it to. But if you're not using it, if there's no exposure, there's no way for the itch to happen. And usage explodes with a real release vs. a beta.

b) People don't test betas, relatively speaking. The amount of feedback explodes for an actual release. Now you'd think that beta feedback would be of higher quality on average (due to people who actually do test betas being more advanced users), but even expert users often hold back on betas despite knowing better.