Insane Programming Java ramblings and finds on the net

Is an OSS project viable with corporate support?

Being a project lead for an open-source project, Spring Rich Client, a lot of times things don't get done due to either manpower shortage or time shortage. Despite wearing the Spring name, we're not a part of SpringSource and as such, don't have the manpower to do all the things we want to do with the framework. Which brings me to the following question: if there isn't a company that has a stake in the survival of the framework, or that generates revenue merely due to the fact the framework exists, is such a framework viable? Just to soothen any panic attacks such a question may provoke within the Spring RCP ranks, I'm not talking about Spring RCP in particular (although there is some relevance to it).

If you look at open-source projects such as Hibernate, JBoss AS, the Spring framework, Guice, ..., you're able to spot a trend: every popular framework has a company behind it with dedicated people, and that generates money on that framework (professional services, consulting, ...). Come to think of it, I can't really think of a succesful open-source project that isn't existing in this format.

I think the right statement here would be that every open-source project is created thanks to all the world-changers out there. But at some point, you need corporate support and a big name behind your framework, or no-one is going to use it. There are plenty of examples out there. Wicket, for example, started out as a SourceForge project and has been adopted by Apache. Result: Wicket is one of the most popular frameworks out there. Who of you have ever heard of jZeno, Sombrero or Jaffa? Here's a hint: they are (or were) all open source web frameworks.

This is one of the most frustrating parts of being an open-source project lead: knowing that your framework is being used more than you'd ever imagined, but getting zero feedback from the companies that generate income due to that framework's existence. Let's take Spring RCP for example. I know for a fact that there are companies out there that are using, and even relying on, Spring RCP. How do I know? I've either gotten questions from them (I'll get back on that in a second), or I just happen to work with them on a project.
Another frustration is some of the questions I get. Sometimes I put a lot of effort in giving an extensive answer, but if someone finds a solution to a general problem, they don't share that solution to the general public. IP stuff, you know. For all I care, IP shouldn't count when using an open source project. You've already committed time to solving the issue, putting it in the framework is only a small effort. Just look at the amount of open-source project forks existing in company repositories... Sometimes one might get depressed.

Perhaps a new license should be created: if you're using an non-corporate backed open source project as a baseline for corporate development, why not donate 1 percent of that project revenue (or budget) to that open source project, say for the first 3 projects you're doing. By the time you're doing the 4th, the funds donated have been put to good use (a new release, possibly dedicated developers, a move to professional project hosting,...) and your company is reaping the benefits from the donations. Due to the donations and the added quality due to those donations, it's even possible that project gets picked up by a company willing to invest in it.
The only problem is see here is greed. It only takes one greedy OSS project lead, not using the received funds to help his project, to tear down the system. But then again, I'm the world-changing type. Perhaps it'll work.

Implementing the Circuit Breaker pattern in Spring with AOP

This is one of my earlier articles

Intro

Most of you are probably wondering right now what a circuit breaker is. Well, it's a pattern I picked up while reading Release It!, a Pragmatic Bookshelf jewel. For those of you who haven't read this book yet, go to the bookstore and get it. It's one of my favorites and it has helped me to become a better developer.

Quoting the book, a circuit breaker 'is a component designed to fail first, thereby controlling the overall failure mode' . Put shortly, it allows you to circumvent a certain subsystem when that subsystem is not healthy.

It can be a very handy component when your system is communicating with several outside systems. When a certain system is failing over and over, you probably don't want your system to keep trying, hoping it will go up again. Using a circuit breaker, you can stop your system, failing fast and more importantly, gracefully.

Combining Liquibase with Spring and JPA

Managing change on source code is easy. Managing change on database schemas is less so. Especially if your application can be used across many database backend (Oracle, MySQL, SQL Server, ...).

Liquibase provides a database agnostic way of managing changes to a database structure. It uses an XML format which contains various changesets for all the changes made to a schema. Ideally, you'll have a changeset per atomic change (adding a column, creating a table, changing an index,...). The beauty of Liquibase is that the database itself is aware about its state. Liquibase implants a versioning table into your schema and uses this table to do the necessary updating.

When using it in combination with Spring and JPA, there are some things you do need to look out for. First of all, the Spring support for Liquibase isn't very big. There's an initiializing bean that updates a schema based on a changelog xml, but that's about it. For example, I wanted to change the names of the tables Liquibase creates for its versioning. The Spring class in Liquibase does not support this feature. Luckily, using the Spring support in Liquibase as a baseline, it's not that hard.