AmazonMP3

To me, open source and open source efforts like OpenNMS are about finding powerful and flexible solutions to difficult problems because the alternatives are expensive and clunky. It seems that too many companies are more focused on customer lock-in and revenue streams based on things like per-node pricing than on addressing their customers needs.

But our industry pales compared to the music industry. I’ve ranted elsewhere about this, so I won’t repeat things here, but I came across something last night that suggests that there is hope.

My wife and I were watching TV and a new Dell commercial came on which showed older technology exploding and being smashed with a wrecking ball while a woman sang Que Sera Sera in the background. It was a cool arrangement of the song (although I am partial to the Sly and the Family Stone version) and my wife wondered who sang it.

A quick Google search turned up the artist as Jennifer Terran. But better yet there was a link to an AmazonMP3 page where the song was available for 89 cents. It was a high quality mp3 (256 bps) and DRM free.

I bought it. I already had some funds at Amazon due to a gift certificate and the process was painless. I had the song before the next commercial break.

I’ve shied away from buying songs at the iTunes store because the iPod is only one of the places I listen to music and most of the music there contains DRM. I don’t want to have to keep up with usernames and passwords. I don’t “steal” music but I do enjoy it, so most of the time I buy the physical CD and rip it once it arrives, although some music executives sick with greed think I should have a copy per device.

Now I have an alternative, and the instant gratification factor means I’ll probably be spending more on music than I have in the past.

One improvement I’d make is to allow for track to album upgrades. At the moment, according to the e-mail I received back from Amazon, if you purchase a track or two from an album and then decide to purchase the whole thing you do not get a credit for the tracks you’ve already purchased, unlike the iTunes store’s Complete My Album feature.

But for DRM free files I’ll live with that.

Quick Roadmap Update

We had a meeting a couple of weeks ago to lay out the roadmap for OpenNMS in 2008. I thought I’d share a few thoughts that came out of that meeting.

First of all, a little history. OpenNMS has always had at least two releases available at a given time. The “stable” or production release is identified by having an even number after the “dot” in the version, i.e. 1.0, 1.2. This is a release with very little code churn, and it is designed to be used in production environments where one would sacrifice features for stability.

The other release is the “unstable” or development release. It’s identified by an odd number after the “dot” in the version, i.e. 0.9, 1.1, 1.3. This is code that could have significant changes between releases, and thus it is not necessarily for use in a production environment. However, there is an exception which I’ll describe in a bit.

When we released 1.3.2, over a year after 1.3.1, large portions of the OpenNMS code had been changed and in some cases totally rewritten. We realized that the next stable release would be a large change and (we hoped) a large improvement over 1.2 and we decided to call it 2.0 instead of 1.4.

In our minds, 2.0 became something of a holy grail. This would be the release with full configuration via the webUI, easy distribution, documentation out the wazoo (grin) and all kinds of other stuff.

We’ve been at it for a year and while closer we’re still not close enough. One has to remember that OpenNMS is still largely a community driven project and it grows as fast as the community will allow it, and we just haven’t had the time and people to implement all of our ideas.

But now we find ourselves with an “unstable” release, 1.3.9, that is more robust that our current “stable” release of 1.2.9 and the twin pressures of getting a new stable release out and trying to squeeze in just one more feature are mounting. So, we thought, why not release a 1.8 based on the current development branch? That became the plan.

However … while a number of daemons have been rewritten and optimized, our capabilities scanner, capsd, could benefit from that treatment. The downside is that it is probably a couple of months worth of work, and I want a new stable soon. We ran into this same situation with the transition from 1.1 to 1.2 – we want stable releases to be perfect but if we have to wait until every feature we can think of is included we’d never release anything.

So we came up with the following roadmap:

We’ll release a 1.3.10 and perhaps a 1.3.11 which will focus on cleaning up all of the current work in the 1.3 branch and polishing it to make it ready to bear the name of a “stable” release. This will be called OpenNMS 1.6. This timeframe for this is in the next 6-8 weeks or so. Maybe not 1.6 proper but definitely a release candidate.

Then the focus will switch to capsd. Once that daemon has been rewritten and tested in the 1.7 development branch, it will be christened 1.8. The timeline for this is rapid for us – middle of next year. By this time we should have the platform needed to seriously work on our 2.0 goals.

The plan for the 1.9 development branch is to focus on a subsection of OpenNMS for each release. For example, 1.9.0 might focus on notification features, the 1.9.1 release could emphasis distribution, etc.

And 2.0 will be out … when its out. (grin)

Our plan for 2007 was four major releases and we’ve had six, so lets hope we can meet if not exceed this plan in 2008. Thanks again to everyone who makes OpenNMS possible.