Recently, ZeroTurnaround made the decision to focus all of our efforts and resources on the JVM Development Tools market and discussed some of the reasons why in a blog post.
There are a lot of good reasons out there; XRebel product manager Geert Bevin wrote an advanced series called 10 Reasons Why Java Rocks More Than Ever why working on tools for JVM development (namely focused on Java) is the place to be. So the 5 reasons stated below somewhat recap this, which I declare not to be an exercise in fanboyism (since I’m not a developer anyway). These thoughts just restate simple truths that become easier to overlook with time. For convenience, we referenced in line the RebelLabs surveys and reports that back up the points I’m making.
Reason #1: The landscape for developer tools is both advanced and developing
In our epic Java Tools and Technologies Landscape for 2014, we [unintentionally] ended up with a total of 14 different technology categories that developers use. One of the final observations was how the JVM technologies out there for developers are welcomingly diverse, with a strong foundation of mature tools available (like IDEs and Web Frameworks) stabilizing another layer of more dynamic tools that are in a state of change or fresh to the market: here we mean build tools, VCS, static code analysis tools and more. It’s a balanced market in many ways, with competing and complementary tools available (we talk about that more below).
Reason #2: We have a pretty good idea of development standards and “good-enough” practices
Are you familiar with the following terms?
- Java Community Process (JCP)
- Java Specification Request (JSR)
- Technology Compatibility Kit (TCK)
If not, don’t feel bad. As we cover in A Short History of Nearly Everything Java, these entities are focused on making sure that all the different moving parts of the JVM, Java and JDK are reliably maintained and monitored so that a billion apps and devices don’t decide to throw a mutiny like from an episode of Futurama. In the last decade of so, we’ve seen a lot of “best practices” (which I’ve renamed to “good-enough practices”, since they’re only good enough until something better comes along) emerge, from methodologies like waterfall, agile, scrum and DevOps to unit/integration/mock/performance testing and peer programming (with or without spooning).
The point is, we have a lot of pretty well-proven methodologies, standards, processes and checkpoints in place to ensure that although Java may be “slow” to be released, it won’t be broken. That’s your job ;-)
Reason #3: We have an abundance of JVM technologies spread across the commercial and open source space
Compared to any other language, the JVM has the most robust and advanced tools segment, and with Java running the show, for better or worse, the Java developer tools segment is clearly the place to be. In this mindmap (courtesy of Oleg) we mapped out all of the selections made by the respondents, and what we can spot is a great mash up of both commercial and open source solutions, working side-by-side in many cases. This encourages a rather creative environment of different philosophies and market approaches and probably serves us all well.
Indeed, when we published 10 Kick-Ass Technologies Modern Developers Love, it was clear that the technologies mentioned are successful regardless of their sales/licensing model; the real reason is that professional services/support companies have risen up to bring the technology closer to enterprises. This is in fact a good sign pointing to growth in developer tools in the medium term.
Reason #4: Developers can express their curiosity by experimenting in a risk-free way
Ask anyone who works with developers and they’ll recognize them as an intrinsically lazy and intelligent bunch. This makes them efficient!
Developer laziness encourages curiosity in shortcuts and easier solutions. With the plethora of interesting technologies emerging in all sectors of development, it’s easier than ever to sample different tools. By the simple nature of being in development, programmers can easily try new technologies in a relatively risk-free environment–as opposed to testing new Ops tools live on production servers and crashing the Gibson.
This sort of environment is like caffeine and guarana (or whatever they put in Red Bull to make your eyes twitch) for the tooling market, in which developers as an overall market segment can not only participate as users, but also become providers themselves and join, volunteer and donate time to hobby or open source projects. Which they do. And it rocks.
Reason #5: JVM developers benefit from an enormous, influential and active community
A long history of community activity, led by open source initiatives and backed by enterprises, might explain why the JVM community is so potent and integrated into the fate of Java and the programming languages on the JVM like Scala, Groovy and Clojure. Referring again to A Short History of Nearly Everything Java, we learned how the JCP actively engages Java User Groups (JUGs), of which there are hundreds around the world (with hundreds of thousands of members), into building a better Java with the Adopt-a-JSR program. Take a look and you’ll also find OpenJDK, which is just that–open (and always looking for contributors).
Combine this inner circle of influencers with many decent sites providing technical content, education and news dedicated to Java and the JVM, and you’ve got a freakin’ great community. Good, original content is so popular that the latest trend is for organizations to move as much writing prowess as they can in house and attract knowledge-hungry readers to their own pages–and I hope RebelLabs sets a good example.
With these concepts in mind, we are positive about our choice to focus our efforts in providing value for the Java developer tools market. In the next part of this discussion, we will make the case that the developer has become incredibly influential in creating new ways for the deployment and consumption of applications. In short, if you want to know what’s going to happen over the next 3-5 years, look at what developers are doing now! Until next time :-)