I've been pretty unhappy with SuSE Linux as of late. I thought 10.1 was well done, but subsequent releases were of poor build quality and in places just sloppy. There were times it began to show promise, only to fall just short.
I've been living inside of openSUSE 11.0 for the past several days, and tried out RC1 as well. All in all it's a very impressive distribution, and I'm surprised they were able to put this level of polish on KDE 3.5, KDE 4 and Gnome at the same time.
Package management, the Achilles' heel of SuSE up to this point, is scores better. YaST2 actually loads its package management tool quickly, and metadata indexing doesn't take decades like it used to. Compiz is nicely integrated, and KDE 4 is actually quite well done. I'm installing the unstable 4.1 packages right now, and we'll see how that looks as well.
There are some speed issues, but then again I'm using KDE 4 with desktop effects cranked up. However, the fixes to package management alone make SuSE a fantastic winner for the desktop Linux space. Honestly, once KDE 4.1 comes out I wouldn't be surprised at all to see more corporate desktops and developer machines turning to SuSE Linux Enterprise Desktop.
Saturday, June 21, 2008
Sunday, June 01, 2008
Counting on Trolls Under Your Bridge
It seems no matter if you're in a huge corporate project or a smaller cadre of independent developers, the rules of managing people and code remain the same. And open-source projects tend to manage people much better than their corporate brethren.
In projects with multiple people involved you have to continually worry about people leaving, contributing crappy code or going on a complete tangent. Usually in corporate life people just want the thing to work, and if it randomly happens to hit production and not have complete show-stopping errors, great. But the code could be complete cruft and no one would care.
With an open-source project, however, you must have complete transparency. Brian Fitzpatrick and Ben Collins-Sussman recently gave a presentation on managing people in OSS projects effectively. Code reviews, definite goals and communicating "just enough" were all key. Hrm... how many commercial software developers do the same thing?
It's not without its difficulties, however. Especially with the kernel, contributions can be a big mixed bag. Sifting the good contributions from the pointless ones can be time-consuming and tedious. So projects are split into more minute portions, and newbies are either mentored or given a sandbox to play in.
It seems like there is a role model out there for taking a wide variety of people with an even wider variety of backgrounds and time commitments and having them all contribute to a well-developed end product. It's a shame it isn't emulated more often.
In projects with multiple people involved you have to continually worry about people leaving, contributing crappy code or going on a complete tangent. Usually in corporate life people just want the thing to work, and if it randomly happens to hit production and not have complete show-stopping errors, great. But the code could be complete cruft and no one would care.
With an open-source project, however, you must have complete transparency. Brian Fitzpatrick and Ben Collins-Sussman recently gave a presentation on managing people in OSS projects effectively. Code reviews, definite goals and communicating "just enough" were all key. Hrm... how many commercial software developers do the same thing?
It's not without its difficulties, however. Especially with the kernel, contributions can be a big mixed bag. Sifting the good contributions from the pointless ones can be time-consuming and tedious. So projects are split into more minute portions, and newbies are either mentored or given a sandbox to play in.
It seems like there is a role model out there for taking a wide variety of people with an even wider variety of backgrounds and time commitments and having them all contribute to a well-developed end product. It's a shame it isn't emulated more often.
Subscribe to:
Posts (Atom)