kontrawize

Find me some code

Thanks to El Reg for pointing out the Koders.com site. It's a speciality search engine that focusses on source code. It seems to have a lot of the open-source projects indexed. So, put in some search terms, find examples of how others have dealt with same problems. Well, find examples of how others have dealt with the same keywords, anyway. That said, can't be a bad place to start if you have something to code but need that spark of inspiration to get you started.

Green hamsters

Apparently green power from hamsters is now a reality. Two minutes of hamster-on-wheel time gives you 30 minutes of mobile phone talk time. I guess that means a full hamster aerobic work-out could keep you on-air for a week.

I wonder how many hamsters it takes to run a bar fridge?

Building software with Maven

Apache Maven is a tool for managing software builds, especially for software written in Java. I've used a number of tools for managing software builds over the years. In my C/C++ days, I used the good ol' make tool, a la Unix. I have also written build scripts using Windows batch files and NetRexx.

In recent years, I've done my Java builds using Apache Ant. Ant is a great tool for specifying how to build a particular piece of software. Actually, it is a great tool for creating all sorts of batch processes, e.g. XSLT pipelines. However, what Ant doesn't give you much help with is managing your software's dependencies on particular versions of other components/libraries. This is where Maven comes in.

However, before Maven, there's an interesting bigger picture here. What do you get when you buy a commercial distribution of Linux? It isn't the software per se, since that is open-source. Part of what you get may be a box with some manuals (which I'm willing to pay for). However, the biggest thing you get from a Linux distribution is a coherent set of software versions that will work with each other. The great triumph of Linux, as I see it, was the creation of version management tools like rpm (the Red Hat Package Manager), which allows a software component to specify which versions of other components/libraries it is dependent on in order to run. With this information:

• your software can automatically abort its installation if the necessary software dependencies have not been installed;
• more sophisticated software installation tools can check which component/library versions you need (and which component/library versions those need, etc.) and then download and install everything that you need in one hit.

Without this facility, Linux would be unusable for the non-gurus of the planet, and those non-gurus make up the majority that Linux needs to win over if it is to be as successful as the pundits reckon it can be.

In that light, seeing how crucial version dependency management has been to the success of Linux, is it going to be less important for your own software builds? The bigger the software project, the more this is going to be an issue. So Maven takes a different view to Ant. Ant is about controlling the minutiae of software builds. Maven is about making each component's build environment and processes as standard as possible, and then managing the dependencies. Maven is build on top of Ant's functionality, but Maven seeks to hide the details of individual builds in a way that Ant typically does not.

Part of the magic that makes Maven work is that there is a Maven Web repository of the most widely used open-source libraries. So, if you try to build something that requires a software version that you don't have, Maven will look in its repository. If it is a standard item, Maven will retrieve the copy from its repository, and not force you to bother with the details. For your own local components, you can tell Maven to use your local repository first, so Maven can be used between teams on larger software projects to manage those version dependencies too.

I'm just in the early days now of moving some builds to Maven. One thing I have learned is that to use Maven, you need to have Web access enabled so that it can download its plug-ins plus libraries from its repository. Once you have downloaded these items once, you can do off-line builds without a live Web connection, but be aware that if you start to use any new Maven operations, you may have to be connected again. This is an issue in enterprise software development environments where software downloads may be tightly controlled. However, I definitely think it is worth the trouble.

Maven focusses your attention on the high-level details that matter most, rather than letting you wallow in unnecessary detail. That's always a good thing for software. Give it a try and let me know what you think. As a new user myself, I'm interested to know how other people get on with it.

A business model for open source, part2

In my earlier post, "A business model for open source?", I mentioned Sun Microsystems in particular because they recently opened an open-source office, and that made them a topical example. I could have chosen other companies as examples, particularly IBM.

However, it was remiss of me not to comment on Sun's recent decision to open-source its Solaris flavour of Unix. My comment was that large companies open-source items that do not impact their core revenues. I don't believe Solaris revenues ever rivalled Sun's hardware revenues, but it has been a tidy earner for Sun for many years now. However, Solaris is really the last of the Unix variants that has held out against Linux, so the writing was on the wall. Solaris as a direct revenue earner didn't have a future. Solaris as a support earner still has a future, and Sun didn't miss the obvious, that you don't get Linux support contracts for free. There may have been commercial pressure on the pricing of Solaris, but there is no such pressure on Solaris support contracts.

More interesting is the recent suggestion that OpenSolaris could overtake Linux as the open-source operating system of choice. That's a big call, especially as I cannot imagine IBM nor HP promoting Solaris over Red Hat or SUSE Linux. That said, for production systems in larger companies, I can see OpenSolaris often being preferred to any Linux distribution; Solaris is simply a more mature variant of Unix that has a long track record in production environments.

If OpenSolaris does beat out Linux in some areas, though, I can't help thinking that it will be another example of an open-source release that is able to beat out its competition because the company behind it has a strong revenue stream from something other than the software itself. Good or bad? I still really don't know.

A Musical Keyboard & Linux

I had a birthday recently, and now I have a Yamaha PSR-K1 electronic (musical) keyboard. It's a riot, definitely a hit for kids.

I run Linux on my laptop, and getting more obscure pieces of hardware to work with it is sometimes more of an adventure than I need. I have a Logitech webcam that is one of my current adventures. However, the Yamaha worked as soon as I plugged in it. I fired up Rosegarden (software for writing and playing music), and it automatically started using the Yamaha as the playback device. Sounds excellent.

It's nice to have an easy win sometimes.

A business model for open source?

A story about some more enterprise-level contributions to open-source had me thinking about just what the business model is for open-source software (OSS). I have seen people talk about business models where they say that you won't be able to sell software in the areas for which there is OSS, but that you could make money from providing support.

That misses the point, though. What is the business model in the sense of who pays for the development work? Sure, some work is done by individuals in their spare time, but a lot of OSS is being developed by large companies. Those companies are paying real money for this work, so there has to be a real business model.

Sun Microsystems is an interesting example. They recently established an open-source office, staffed by Simon Phipps (who, on my one and only evening in Dublin, took me to a sushi restaurant. But that's another story). Sun's major OSS contributions to date, at least in my mind, are StarOffice and Solaris. Java is similar, being free, if not OSS according to some purist definitions.

Sun, by revenue, is a hardware company. The software that they are open-sourcing wouldn't be a great money-spinner for them as a commercial offering, but it does help establish the credibility of Sun hardware as a platform for enterprises to deploy their software on. This is part of the same golden rule I see for most OSS - you open-source software that isn't part of your core business, that isn't part of your core revenue streams.

Why? Well, large companies often develop software tools that they don't want to purchase, either because of outright purchase cost or because they need something different to what is on offer. Having written it, they face the ongoing cost of maintaining it. However, if it isn't core business, they can open-source it, and hopefully a community of users will take over the maintenance for them. It's somewhat win-win. That is, unless you were a software company that had a commercial offering in a space that suddenly has an open-source alternative. You can be in serious trouble then. In a lot of cases, it is the OSS alternative that will win. When there is no purchase cost, individual IT developers can bring in a copy of an OSS tool, do something with it, then show their employers and tell them that it won't cost any further money in licences. Project managers with strained budgets love that story.

Now, that isn't such a bad thing, and I use a lot of OSS myself. However, if we end up in a world where most software is written and/or supported by companies for whom it isn't core business, that could introduce a serious level of operational risk. Sometimes you buy software for an enterprise because you want software from someone whose livelihood depends on that software working as advertised. When software isn't the core business, that imperative is gone.

We are a long way from this scenario yet, but it is a trend that I will be watching.

Unaware of RSS?

Apparently the public are unaware of RSS. I guess they must be completely clueless then about the Atom API that hopes to replace it. I'm not surprised by the survey result. I found that a friend of mine, not particularly IT-literate, had a blog. I told her that I was receiving her RSS feed. She apologised, and told me that it must be a virus on her machine. I reassured her that the RSS feed was a good thing. Knowledge of RSS is far from a prerequesite for being a blog author.

That said, every time I see Tim Bray talking about the latest blog statistics, the statistics are still going through the roof. So if the public don't know about RSS or Atom now, they soon will. They may never know them by name, but they'll get the idea - you can receive updates from blogs if you want, instead of having to check them manually. That's all most people need to know.

Is Skype too geeky?

I was interested to read in a couple of blogs (Jeff Clavier & Tim Bray) that Google is going to try to give Skype a run for its money in the instant-messaging and VOIP-telephony markets.

I use Skype, and I don't mind the service (although I'm disappointed there aren't any videocall Skype plugins for Linux yet), so I wondered whether Google's move would impact Skype, or whether Skype's early lead in the area would win out.

What answered that for me was a BBC TV news report. Google's entry into the VOIP market was considered sufficiently mainstream it to appear in the evening news. However, Google's competitors were said to be a couple of other big players (I think it was Yahoo and Microsoft). Skype didn't get a mention.

This is a battle that will be won on public perceptions as much as on technical merit (VHS versus Betamax again, as they say). Right now, Skype has a lot of geek chic, but does it have a public perception? I think it is going to need one, if it doesn't want Google to overtake it.

Note: I don't give investment advice. This is just a personal comment, and should not be interpreted as investment advice.

Do you choose applications or operating system first?

According to The Register, XenSource have demonstrated Windows XP running on their virtualisation software (as opposed to running a *nix operating system). This is software that allows you to run multiple operating systems on one machine simultaneously, without having to reboot to change from one to the other.

I run VMware on my PCs, including my laptop. That means I can run Windows when I need or want to, or a *nix, including Solaris. It's great to have that kind of choice. When Apple moves from PowerPC to Intel processors, I would be brilliant if I could run OS X as well.

Which brings me back to the classic question, do you choose your applications first, and then an operating system which will run them, or do you choose the operating system first, and then the applications? If you are lucky enough to have this choice, I think there is a new answer:

1. Choose the applications you need first (if possible);
2. Choose the virtualisation software that can run the different operating systems you need for those applications;
3. Choose enough operating systems to run those applications with your virtualisation software.

It's an incredibly liberating thing, not to be tied to one operating system any more. So good news to see vendors giving us choice. Combined with the virtualisation support being added to processors by AMD & Intel, things are looking pretty darn good, as they say.

JRequire = good idea

JRequire is a simple tool that allows you to track whether your Java unit tests (JUnit) are covering your requirements. Checking code coverage of unit tests is a standard part of enterprise development, but check requirements coverage is novel.

To use JRequire, you have to maintain a mapping between your unit tests and your requirements. That means some effort, but it isn't going to get much easier than that. Mapping unit tests to requirements is an indirect way to map code to requirements, but I'm thinking that it could be a useful way to do it. Requirements don't necessarily map neatly to particular classes or methods, but I can see how they may map more neatly to unit tests, especially when testing of groups of related classes, rather than just individual classes.

Limitations? Well, sometimes requirements aren't the right thing to map code or unit tests to. For example, where use cases have been developed from requirements, development may be based on the use cases. In that case, you want two levels of mapping, code/tests to use cases, and use cases to requirements. More generally, allowing multiple levels of mapping is what you would need for a large enterprise project.

All that said, hats off to the JRequire folks for coming up with something so simple and useful.