The Developments at SpringSource

The blogosphere has been abuzz with the news that SpringSource is going to be charging for support, and for maintenance releases. SpringSource is becoming a more traditional, more mainstream enterprise. Rod Johnson, one of the progenitor's of Spring has seen Spring become like hibernate in that though it is not a standard it might as well be.

Now they SpringSource, the entity which focuses on Spring development are looking at ways to extract value out of that popularity, but also, I think, take Spring to the next level.

And the developments are not unusual, or should not have been totally unexpected. How many other open source applications have gone the similar route. Redhat linux, JBoss, to a lesser extent hibernate... What other way do you monetize and open source application apart from selling support etc...

From all that I've read, the change to the release system is that "official" releases will only be available to non paying customers for three months after an official release. So 2.6.2 will only be made freely available if it is released in the 3 month period after version 2.6.

The bug fixes that go into any release will still be put into the source code and the licensing of the source code has not changed. So, then, why can't some developer checkout the source code, build it, and then make that freely available for all the other developers. I guess the only draw back is that it's not an "official" release. It's like a new car is only a new car if you drive it off the show room floor.

Personally, I don't have a major issue with where Spring is going. I think it's an acceptable way to build a viable business model out of their operation. Though it may serve to alienate purists, it might also cause people on the fringes to be brought in.

Programming is Hard

I can remember my brother once remarking that "Programming is Hard", and I'm not sure he realised the importance and relevance of what he was saying.

On our large project - about 20 Java devs - I monitor the checkins and do some basic QA on them. The developers in this environment, who are apparently fairly good, still make school boy errors.

Fortunately we have hudson setup to do all the checks possible - checkstyle, pmd, findbugs and cpd - and so I can find most of the basic mistakes, like copy and pasted code for instance. But then often I find more complex issues, just bad design for example, and I've often thought about this issue.

I also maintain that computer programming is engineering. There is debate about this, but I think there are enough similiarities with "classic" engineering for it to be labelled engineering (I think it helps quality if you call it that).

Why then does computer programming not have the same aura that classic engineering has, and also the same obsession about quality...

Two reasons...

The first one is safety. When building a computer programming you're not building a bridge and thus you do not have to worry about people dieing if it fails. A "bug" in a bridge could prove very costly, not only in terms of money, but more importantly in terms of people's lives. There have been many instances when bridges have failed and their failure is put down the human error. Something that would have been called a "bug" in a computer program.

The second one is that the programming world is abstract. The result of this is that the world is a lot less limited. You're not limited by something physical when building a computer program. The result of this is that the barrier to entry is a lot lower, it's much easier to get into and also that it makes programming "easier" than other engineering. Easier in quotes because I think the problem we have with quality when building computing systems is because people think it is easier.

Programming with Quality is IMHO every bit as hard as building a bridge successfully or desigining and building an alarm system. If we want to produce quality we need to put as much effort into it as an qualified and certified engineer would put into building a bridge. We cannot think that our often mediocre, slap-dash efforts measure up.

Problem is, if you're reading this, you probably do see yourself as on a par with an Engineer.