...we should keep adding new features to the language or whether we would be better off making a clean break and working with a different, new language on the same JVM.
There's definitely a big increase in excitement about alternate languages on the JVM, like JRuby, but there are also people who want to bring features that are popular in those languages into Java, like closures.
It's very unclear what route to go there; it's not clear to me at all. There are people who say "Java has to have closures" and, early on, I was one of those people. And, now that I look at it with a little more thinking, I'm not sure Java should really have closures.
Maybe a different language should be created which is like Java and has closures. It's not clear to me that bolting these things on afterwards works.
How is this different from the open-source projects that Red Hat and JBoss use?
We have always had a problem in the open-source world of things changing fast. You can see it as a bad thing, or you can see it as a good thing. Traditionally, when you take an open-source project, there is a problem with developers getting bored or fixing the errors in a release from a year ago, calling it 2.0 and breaking everything.
To an extent, all software has the problem with tension between backwards compatibility or fixing mistakes, and the open-source world typically goes with fixing mistakes, rather than backwards compatibility.
I think that's actually a good thing; you should fix your mistakes even if it causes pain for your users. It's an upfront pain, rather than a continuous tax upon them as time goes by.
To mitigate that, what we've needed is companies like Red Hat which will commit to support existing versions of projects for five or seven years. I think that commercial backing for the open-source project is critical if open source is to succeed in the enterprise, where people are planning projects that have decade-long lifecycles.
The threat of forking... forces us to keep our user community happy, to actually solve the problems that our community are having
Gavin King, JBoss
People are often uncomfortable with the split business/distribution model that Red Hat has with RHEL [Red Hat Enterprise Linux] and Fedora. They often ask: "Does that mean that the enterprise version is better?" No, Fedora is the better version.
Fedora has all the latest and greatest stuff that someone thought of in the shower in the morning and thought "this is the coolest thing ever". [The] trouble is that you cannot support that for seven years. I think you mitigate the problem of a lot of crazy features by having the split model that we have at Red Hat.
The other half of it is the problem of forking. Forking is one of these great selling points of open source — the freedom to fork. But, if you look around, you tend to see that well run projects fork very rarely. I know they had a whole lot of forking in the BSD world.
JBoss has basically never been forked; Hibernate has never been forked; most of our projects have never been forked at JBoss.
The reason for that seems to be that the threat of forking seems to keep the owners of the main branch honest. It forces us to keep our user community happy, to actually solve the problems that our community are having. We know that, if we don't solve those problems, someone will start their own fork of Hibernate, solve the problems and compete against us.
I think forking tends to be a good thing; it forces us to do the right thing, instead of providing much of a threat.
Now, on the other hand, a language is different to Hibernate or JBoss. A language has a much greater cost in complexity, in lack of stability than there is for an API, purely because of the vast amount of software that is written to it and the depth of coupling available there.
