We've discussed some of the fallacies that are rumbling through our industry at the moment. Now let's get to some facts and what JBoss is going to do to address them. And this brings us finally to our position and vision behind JBossEverywhere: it is ludicrous for us to discard the experiences, code and communities that we've built up over almost a decade of development. JBoss and open source middleware are intricately linked. Since it's inception back in the early 2000's, JBoss has had various missions and has succeed at them all. Some closed source companies have had to change as a direct result of JBoss. Some have even gone out of business. It's arguable that JBoss has also contributed to the success of a number of other open source projects and companies. Since the acquisition by Red Hat, the JBoss brand has grown more and more successful too. But fundamentally our success is not simply the revenue that we make, though of course that's important (we all like to get a monthly salary!), it's better measured in the number of projects and platforms we have and their technical and community maturity. This isn't looking for plaudits, it's simply a fact.

For the past few years we've been focused on Enterprise Middleware as it is defined in the context of J(2)EE and hence servers and mainframes. That isn't going to go away and Red Hat/JBoss will continue to be a strong voice in the JCP Executive Committee as well as the most popular implementation. But we see so much more applicability for what we have when we look beyond these environments. And yes, that means beyond the current definition of Cloud. As I said above, there are more processors sitting relatively idle today that people will want to tap into eventually. Some of those processors may well be sitting in your home or office now. Rather than those communities having to reimplement the wheel, we will be working with them to ensure that the perfectly good wheels we've got can be positioned in those deployment environments too. We are seizing ubiquitous computing.

So where will we be in the next 5 or 10 years? Well for a start I'm pretty sure that Java will still be the dominant runtime language and that the Java EE 6/7/8 Application Servers will be at the forefront of enterprise deployments, with the JBoss implementations at the front here too. But developers will always want to use other languages that are more domain specific. For JBossEverywhere this just means that we'll be ensuring that our runtime is available across a much wider set of deployment environments and exposed through as many other languages as makes sense to our communities. If that means we have to develop new projects from scratch, then we will. If it means we have to write in other languages then we will (TorqueBox is only the beginning!) If it means that we have to modify some of our existing projects to better sit in, say, a car engine management system, then we'll make those changes. But I believe strongly that many core enterprise requirements can be met today and in the future by our existing implementations.

Now you might ask why I'm so positive about the future of Java and Enterprise Java, when we keep hearing so much doom and gloom? Well I'm not going to suggest that there aren't problems with the current Java processes and if we were happy enough to be lead through this period then we'd have problems. But we are a leader and we won't sit idly by and let things stagnate. You only have to see this with some of the new standards we're pushing, such as JSR 347. And a lot of our rearchitecture of JBossAS 7 and the modular services container gives the ability to look at multitenancy and multi-core approaches.

So can I make a fairly obvious mission statement to attract the soundbites? How about this: if JBoss doesn't seize the ubiquitous computing landscape then it will be displaced by others? I think that counts So how are we going to do this? Here are my four steps to succeeding.

• Step 1: make our projects highly embeddable and dynamically configurable. Take a look at the keynote for an example!
• Step 2: make our projects and platforms available through a range of different languages and not just on the JVM. Scala for instance!
• Step 3: make our projects known about and open to a much wider community of users and developers. Just because someone isn't interested in using a project within an application server, doesn't mean they are irrelevant. For instance, jBPM 5 running on Android!
• Step 4: keep pushing for improvements in the Java language and the JVM, as well as looking at other domain specific languages or extensions.

So if you're in our communities or just thinking about moving into the Java space, what should you do? Well here are a few recommendations:

• Get involved with our communities are feed in your requirements, as well as code.
• Encourage your developers to experiment with other languages that run on the JVM, and our implementations if possible, such as TorqueBox.
• Talk with your teams about their mobile requirements - they will almost certainly have them and knowing about them now will be better for you than having them creep up at the last minute!
• Create a tiger team to specialise on constrained device applications.

JBoss defined open source middleware for the last decade, and arguably influenced strongly closed source too. We are defining it now for the next decade at least! If you want to stick with legacy frameworks for developing languages, then knock yourself out. We'll work well with them, just as we do today. But really, we can do so much better! JBossEverywhere isn't about telling you what you already know you need! It's about showing you what you will need in the future. This is not just about improving JBoss technologies, but about improving the way in which people will work and interact!