Too much travel makes your brain into pudding. It’s like being hung over, except you didn’t have that nice experience of being drunk. As I work towards a more serious write-up of SpringOne, here are some quick notes a la Voltaire.
Earlier this week, I was at VMWare’s SpringOne conference, covering announcements and new work from their SpringSource division. They launched an integrating cloud-based software development suite of tools, several technology partnerships with Google, and started to outline new integration needs from the social, mobile, and database world.
The release of Code2Cloud is the most interesting announcement. Working with TaskTop – mostly TaskTop it seems – VMWare (or “SpringSource,” as I’ll call them) has put together a good looking approach to doing cloud-based ALM. They of course want to move away from the idea of “ALM” (good council, and one of those Three Letter o’ Death that our own James Governor has told people in the past to avoid) but you’ll pardon me using a known quantity as a crutch to talk about “all that stuff other than the IDE and complier that you use to get software out the door and manage the project.”
Since leaving the programming world, I’ve been envious of teams who could use hosted services like Rally and VersionOne, along with the host of other, well, hosted tools. Those tools tend to manage the artifacts of an Agile process: tracking the “stories” and features that should be built, what phase of the development cycles they fit in (the “iteration”), who’s working on the item, and how far along it is up to completion.
In addition to that issue tracker, there’s version control and your build system. Both of those have been ripe for moving into the cloud, and the ability git provides to do synchronized web style use in git (meaning: you can pile up changes and even use the tool offline) takes care of the unreliable cloud problem most people would probably carp on.
Cloud-based builds are an area that many people, and stealthy startups, have been interested in over the past few months. It makes sense: builds are processor intensive and, as such, a perfect match for the “bursty,” elastic functionality a cloud would provide. Also, as one of Sun’s hosted projects was shooting for, cloud-based builds open up all sorts of platform testing and compiling options: maybe it’s easier to compile to some weird HP-UX version if you just rent that node as part of your build cloud.
The tough nut here will be convincing developers that this system is as open as TaskTop and SpringSource would tell you it is. While SpringSource obviously wants you to use their stack top to bottom, Code2Cloud properties to be an open and interoperable pile of components. Thus, even if you weren’t using Spring, you could use it. One Spring use I talked with said he liked the setup, but didn’t use Spring’s Tools so he wouldn’t be able to use it. And, besides, he said, he already had all that ALM stuff setup. That’s the kind of quick perception to get over by showing, not marketing, as it were. We’ll see once it comes out, sometime next year they say.
I have a short, video interview with TaskTop on Code2Cloud that should be up soon. Also check out Israel Gat’s take: as someone who’s interested in optimizing the development process from the perspective of management, he’s esp. interested in the ALM-we-shall-not-call-ALM innovation here.
Also of interest were the three integrations that Google and SpringSource announced.
Sorting out Google’s angle on the developer-front can be a freaky walk down memory lane. At the end of the day, the reason they do most things is “to make the web a better place.” The more people that use and enjoy the web, the more Google ads they see, the more clicks there will be, and the more money is made, and layering in the collection of data that allows Google to better do that targeting and connivence advertisers that they’ve finally solved Wanamaker 50% waste rule of advertising, and you’re set.
When the stranger lady dumps billions of dollars on your desk each quarter, you don’t worry too much about direct revenue producing products on a quarterly basis. Hence the feeling all too often that Google isn’t operating under the same strategic pressures as other companies.
That’s all to say, when you look at partnerships Google does, you can’t always look at it through the same lense you would other companies. You almost have to take on that cutely, starry eyed attitude most Googleers have: we just thought it was a good idea and Larry and Sergey agreed!
To the Google/SpringSource announcement, then. The first two items – integrating Roo and GWT can be taken at face value as just a “good idea.” GWT has been successful, and it’s certainly one of the UI toolkits I about (Java) hear people using frequently.
Integrating together Spring Insight and Google Speed Tracer is half “just a good idea,” but also ties up with Google’s enterprise cloud strategy, AppEngine…