aporem.net

I came across this advice on niche OSS projects. It is sound, not too long and I fully second the wrap-up:

So getting back to your project, I think that may be what you need
to explain to your boss: that substantial work is needed to make
software *usable*, and that’s a prerequisite for use, which in turn
is a prerequisite for contributions. If that’s your goal, then you
need to work more. If not, then please make it OSS so that when
I stumble upon your project in 3 years and want to use it, I don’t
need to reimplement it from scratch first.

This short paragraph defines the aims of most small programs: either it’s useful and will live on it’s own, or it will die but eventually help someone in the future who picks up the pieces.

Almost a week ago, the status report for FreeBSD related projects has been published. It covers the events from January to March this year.

The highlight is surely the integration of Sun’s ZFS-filesystem, which will be part of FreeBSD 7.0.

Other than that the main reports are:

• Xorg 7.2 — coming soon
• Building Linux Device Drivers on FreeBSD — works only for USB web-cams for the time being
• Import of trunk(4) from OpenBSD — aggregation of network interfaces is such a cool feature!
• SMP Scalability — works pretty good up to 8-CPU systems

The full report can be found here.

Only 8 days into his new job, Ian Murdock gave an interview about his future plans: He wants to close the ‘usability gap’ between Solaris and Linux.

It’s no revelation that there is a gap between Solaris and Linux, but until now I didn’t found it explained in a such simple and clear manner: Solaris has very good technologies, like Containers, ZFS, DTrace but lacks on the side of a simple installation or a powerful package management.

I would like to quote one question he put up and which explains just everything: “So, could we take all that stuff above Linux and put it above Solaris in a way that does not leave behind all of all the differentiating features of Solaris?”

It’s just the way FreeBSD works since 1993…

The KDE Community has agreed on a release plan for KDE 4.0. The goals are pretty ambitious, given that besides the change to QT4 there are plans to switch to a new desktop metaphor, add a desktop search engine, improve the hardware integration, and add RT capabilities.

So far, it all sounds reasonable. But reading the announcement, it struck me at once that this schedule has no room for errors: there is just one Alpha, Beta and Release Candidate planned in!
Given the size and complexity of KDE and the ambitious design goals this is simply unrealistic.

The first milestone (subsystem freeze) already passed by and had a slip of one day. I don’t want to be pessimistic, but it’s going to get worse, although I don’t think that the first Alpha release will slip that much. (I’m betting that there will be a second Beta or RC release.)
I want to stress that I’m not delighting myself on the possible misfortune of others, I’m an avid user of KDE myself, but setting oneself an impossible schedule isn’t helping anyone.

So you can watch the schedule being adapted here.