“We believe the current [platform clouds, such as Azure and App Engine] are incomplete,” [VMware senior director of cloud and application services Jerry] Chen says. “There is no one platform that is multi-cloud – private and public – and no one cloud is architected, out of the gate, to be extensible to many different frameworks and many different languages.”

The Cloud Foundry offering from VMware is looking like one of those obvious, good things I rarely expect Big Companies to do. Of course you’d want a portable PaaS layer that ran Java, Ruby, JavaScript, and other languages. Of course you’d want the company to actually run their own cloud instead of having to sort through “partners.”

In summary, they’ve put together a “bring your own PaaS” with wide language support and a VMware run instance you can use as well, if you don’t want to bring anything and just go directly to a cloud that has it all wired-up.

The most critical thing for VMware to do is to let this “open is best” philosophy play out in their application development strategy. VMware’s current fortunes were built on distinctly not that philosophy and it’d be easy for the kernel geniuses who must hold much of the corporate power to derail the appdev strategy, which is a much different beast than virtualization and other business models closer to the metal than the glass.

Overview via Press Pass

Nancy Gohring of IDG sent over a few questions on the topic (see her piece), so why not inline the answers here? (I’ve summarized the questions, so they’re not directly Nancy’s):

How does this fit into the context of existing cloud and PaaS offerings? It’s difficult to know completely since the offering is still in beta and the pricing isn’t available. That just covers the “.com” part of CloudFoundry though. I would think that developers would be more keen to use a packaging put together by the Spring folks, Java developers at least. When it comes to PHP, Ruby, JavaScript, and other future platforms there’s a lot of street cred VMware has to earn. But with this offering, it’s looking technically possible – it all comes to down to community and developer marketing.

As a counter example, Microsoft has to work very hard to convince developers that it’s not some kind of “evil empire” when it comes to locking in developers to Azure. Somehow Amazon (which is pretty “open,” actually), Google, and Apple get free passes on this: the perception that a ready user base and that there’s money on the table for the clever app developer in Apple-land gets developers to put up with the otherwise heinous “developer relations” Apple does.

Will this help move developers to adopt PaaS? They’re doing the right things to position themselves well: not just being Java, hosting on GitHub (an obvious thing I wouldn’t expect any BigCo to be “smart” enough to do), and providing the PaaS layer as open source for developers to run where-ever they like. Other PaaS vendors typically choose a point of lock-in to monetize every install on, where-as what VMware appears to be doing is trying to create a giant pie of which they only monetize a several hefty slices. I hope that’s what they’re doing at least: the bad thing would be for their business folks to worry about monetizing every single Cloud Foundry instance. Coming from a shop that makes its money selling licensed software and that seems to be fast trying to be the new Microsoft, you always have to understand where VMware is going to take it’s cut and see if that fits with your architectural plans. So far, CloudFoundry looks OK on that front, though.

What’s the “big picture”? So far, most people have been pleased with this. (Although @williamlouth claims to need facial reconstruction after looking at the code.) I haven’t checked out the code or anything [over the next few weeks, expect lots of snarky commentary from those who do], but the open nature of this and the wide-range of languages they’re targeting is looking good. If VMware can make Java just one of the many technologies that run on their clouds and if they can allow anyone to use their cloud software without having to give a dime to VMware or use their tools (see “The VisualStudio Test”), they should have a good chance at building a big cloud ecosystem that they can siphon cash off from. It’s a long play, but this is a good time to be putting all the pieces into place: all of their competitors are for sure.

Competition

Cloud Foundry can be deployed in public or private clouds. It runs on top of vSphere and vCloud infrastructure but can also run on top of other infrastructure clouds. Our partner RightScale today is demonstrating the deployment of Cloud Foundry on top of Amazon Web Services. Because of the open architecture, it could also be implemented on top of other infrastructure technologies like Eucalyptus or OpenStack. –Steve Herrod, VMware CTO

Here’s what I’d expect from the competitors:

• Amazon – as always, they’ll say nothing and just keep putting out new services. Perhaps they’ll lower prices, as they often do. <EOM>
• Microsoft – as I’ve said before, Microsoft is freaked out about VMware. They want to keep their existing Microsoft developers from moving and don’t like the ground moving under their Windows-shod feet. Microsoft will talk about integrated development and ops tool-chains (VisualStudio!), how you can run Ruby, PHP, and JavaScript on Azure, and say things like “if you go with VMware, next thing you know, you’re re-writing all your applications in Java!” Really, Microsoft just needs to speed up it’s cloud developer portfolio be it in betas (as Cloud Foundry is) or whatever. The Azure Appliance needs to get out there to cement in the excellent private cloud talk they started up at MMS.
• Google – what with an existing Spring partnership, this is odder. Google likes to brass-ring to open when possible: we’re more open. People always list Google as a major cloud vendor, but I must have my head stuck in the cupboard because I rarely, if ever, hear about people deploying apps on AppEngine. Google Marketplace integrations, sure, but when’s the last time you heard about some mega-supercool thing on “Google’s cloud” that wasn’t just “Google’s own SaaSes”? Really, Google’s time is probably better spent on things like Android, Google Apps, and avoiding being disrupted in Google Search and the ad revenue it drives. It’s odd to think of Google as doing as well at cloud developer relations as others could.
• Rackspace, OpenStack – in theory, these guys exist below the PaaS layer, but the competition from PaaS stuff like Cloud Foundry is The Battle for Developers to Care. If the PaaS takes care of all the operational concerns, the IaaS layer becomes irrelevant enough that developers don’t care. It’s like the x86 server market: a tough layer to be in because the lack of differentiation based on technology is almost in there by design. All that matters in price. What you’d want to see from the OpenStack folks is rapid enablement on Cloud Foundry and any other PaaS layer. They really need to shoot to be, as The Register put it a while ago, “the Linux of the clouds” and that means lots of effort to make everything work on OpenStack. The same applies for Eucalyptus, Cloud.com, and other cloud vendors. PaaS folks like CloudBees are a slightly different case: PaaS startups main hope is to use their scrappy smallness to out-innovate big ol’ VMware.
• IBM – at their Cloud Forum last wek, these guys already laid out their reply, and it’s pretty solid if you’re an enterprise-minded person: enterprise applications are complex. IBM has been doing business work for a 100 years. We know our stuff, and yours. Good luck with those other guys. Their launch of actual cloud offerings – the two SmartClouds – last week is more important. IBM just needs to move past, way past, the dev/test stage of cloud they’re in an re-discover developer relations big-time. Once they hammer out the path between “Enterprise Software Development” and “Cloud Development” (using dev/ops as a sort of lubrication, if they can understand how it’s different than ITSM, which is apparently “dead” now) and update their portfolio appropriately, they could do well. Speed is the problem here. As Amazon and the dizzying, fragmented array of open source technologies used there-in has shown, marketing to cloud developers has a distinct first mover advantage, if not a “fast and quick to change” advantage. Their other tact (which is far more likely to suck up all the marketing-oxygen) is to speak to the “C-level” and talk about applicationssolutions, costs, and “industries”: the technology is just some details for those poor saps who live their lives in flying metal-tubes to sort out.
• Salesforce – as with Google, there’s partnership’ing here to consider. Salesforce has declared that ruby is the language of the cloud, not just SaaS CRM, so they clearly are looking towards general cloud development with their Heroku acquisition. The advantage Salesforce has is zero allegiance to legacy (on-premise) IT and IT departments. In fact, Salesforce would probably be just fine – if not prefer – the IT department to go away. Most of the other elder companies working in this space don’t have that luxury. Most existing vendors feel the need to comfort instead of destroy-cum-transform legacy IT people, products, and models. Salesforce just has to demonstrate how they can make Heroku better: what can Salesforce+Heroku do that Heroku couldn’t do on it’s own?
• Red Hat – we haven’t heard from the Red Hat cloud story in awhile. With Makara they have PaaS technology and, as you’d expect, they’ll fall back on their “we’re truly open, what-are-you-gonna-trust-THEM?!” posturing. In theory, Red Hat should have the same check-boxes as VMware does here, minus running their own cloud (or maybe they will?). Their big event is coming up in a few weeks, so you’d expect to hear a lot there. See Derrick Harris’ commentary about small-fries in the PaaS market for more here.

What most BigCo’s wanting to get into the cloud development space fail to recognize is that cloud development has little to do with the massive, billions of dollars worth of existing code out there. It has almost everything to do with green-field development. Cloud has little to offer legacy applications*, at the moment. Most everything cloud has to offer is for new applications. As I’m fond of saying now: if it ain’t broke, don’t cloud it.

A company going after cloud development would start talking about how cloud allows you to deliver new functionality in your applications: what new features and software development processes does cloud allow that legacy models simply can’t do? I’m pretty bad at this myself, but I’ve taken a whack at it from time-to-time: “Useful things to do with the cloud, developer edition” and “Considering PaaS,” for example

(* Some of IBM’s announcement last week show them honing in on what cloud can offer for legacy support: solving all sorts of operator things like back-ups, replications, and slicing out cloud-friendly parts of things like SAP installs.)

Misc.

On the meta-level, the almost complete focus on developers highlights how operations obsessed much of the recent (private) cloud talk has been. It’s almost as if the rhetoric of this Cloud Foundry announcement is implicitly saying: all that doesn’t really matter to developers, they don’t care about those “legacy” corporate IT concerns. I like how Stacey Higginbotham puts this point as well:

Charles Fitzgerald says that Cloud Foundry will sit on top of platform plays such as OpenStack, but in truth it is likely to hurt that effort by obviating the need for enterprises and other developers to worry about the underlying infrastructure platform. For those who want to build out an app, electing to deploy using Cloud Foundry means the developer can choose where to host its app without ever caring if it’s using OpenStack.

Also of note, Rod wrote that the long-awaited Code2Cloud is finally coming out “in the coming quarter.”

More

• The official press release, including a quote from our own Stephen O’Grady.
• Rod Johnson’s overview of Cloud Foundry.
• Write-up from VMware CTO Steve Herrod.
• the GitHub repository for their various Cloud Foundry projects.
• Stacey Higginbotham covers Cloud Foundry for GigaOm.
• Cade Metz covers Cloud Foundry for The Register.
• Quentin Hardy covers it: “Compared with the early ‘nineties, when I was doing this at Microsoft, the whole open source world has changed,” [Paul Maritz, VMware’s chief executive] says. “It is so much bigger. Second, now it is about driving things at a higher level – not just in a single (software) framework, but to lots of systems.”

Disclosure: VMware, Cloud.com, Eucalyptus, GitHub, Red Hat, Salesforce, CloudBees, Microsoft, Rackspace Cloud, and IBM are clients. See the RedMonk clients page for others.

Both Chris and John were interested in what he might do at Google, and wondered why no one had said what he’d be working on. Here’s the amalgamation of what I sent to Chris and James:

Working on…?

I don’t think it’s that odd that they’re not speaking to what he’ll be working on. Gosling is someone you would hire and sort it out later. I wouldn’t be surprised if he continued to do research around Java, or just software and systems in general, instead of getting glommed onto a specific product. He was doing a lot of research stuff at Sun last I heard. While he wasn’t on “the front line” of the Java world (having moved from there to research, as I understand it), I’d wager that Google is happy to stack more Java leaders into its ranks. As I recall, the two major languages at Google are Java and Python (I’d think JavaScript is very popular inside Google as well). Java is an important language for Google then, and having “The Father of Java” there is a nice thing to have.

His familiarity with the full life of Java, patents, and such might also be helpful for their ongoing Oracle legal problems, but really, that’s just arm-chair lawyering: I have no idea on legal strategies.

Community Halo

Google has hired some of the larger thought- and technical-leaders in the Java world. Having them on-boards and, important to this point, working on Java certainly would give Google a bigger voice in the Java community.

And considering that Oracle is currently suing Google for the equivalent of being a “bad citizen” in the Java world (that Dalvik thing is still going on, right?) it would also be entertaining to see several of the old guard of Java on wrong end of the lawyer-stick.

I think the main thing is Google just collecting up important Java people, though. There’s a bit of hand-wringing in the Java world at the moment about who the leaders should be: things like Oracle suing Google and using trademark as “community management” tactic in the Hudson/Jenkins dust-up has frustrated some developers in the Java world.

It’s hard for many Java developers to feel sympathy for anything less than a very, very open Java after it was open sourced many years ago. So you throw in the ASF/Harmony dust-up (where Oracle effectively shut-down the ASF’s project to crate a new Java runtime) and developers are unsure what future controls Oracle will try to foist over the Java community. (For the other angle, see this nice pointer to Oracle’s side of the beef.)

Now: it’s not like there’s a tremendous amount of super-virtuous organizations in the Java world at the moment: at the very least, everyone is fearful of being too open from the demise of Sun, whether that’s warranted or not.

Pulling out of this rat-hole, I’d just say that hiring someone like Gosling is a good move if you care about Java. He’s clearly a good coder and a legend in the field, as it were: it’s exactly the kind of person Google likes to collect up and use its cushy position to fund and, hopefully, let flower into new innovations.

Also, if you’re interested, check out this interview (as a podcast) I did with Gosling at JavaOne in 2008.

Oracle hosted a “fire-side” chat about Java this past Tuesday, giving an update on how the community is doing and taking a few questions. John Waters sent a few questions over for a piece published as “Oracle Speaks Out on Java, One Year Later…Sort Of.” Here’s the complete answers I wrote up:

Q: Are user groups the heart and soul of the Java community? Do they have this right? Is this a good strategy?

Java user groups may not be as powerful as they used to, at least in the US, but they’re still a significant part of the community. The proof? User groups are, pretty much, volunteer-led. For some there are incentives to get involved – free stuff, networking, fame, etc. – but you can look at the participation as driven mostly by the user group members passion. I don’t know figures on user groups, but anecdotal, I tend to see them still well attended. There’s fragmentation and interest in other platforms and groups as well, but Java User Groups certainly aren’t dead-wood floating up on the beach.

The Java community has many hearts and souls, of course. But, if you were to pick one community, it’d be hard to go wrong with user groups. The only issue is that you might be missing out on some of the edge cases and emerging Java developers who aren’t interested in only the Java world. There’s probably some Dalvik, Android, and other mobile developers that the overall Java community should be looking towards, and also many of the new database types (broadly, “NoSQL”) and app platforms are Java-based, but are far from “official” Java. A recent post from Stephen O’Grady outlined this “mutation” well.

Q: What do you think of that idea of Big banks and telcos being brought in to the JCP to represent “the user”?

That makes perfect sense if you want to promote the use of established “users.” Big enterprises certainly use Java and depend on many existing applications (off the shelf and custom) that are built on Java. I’d suggest that Oracle probably knows how much revenue is generated by such big customers and, thus, how important they are to the financial side of the Java world and, further, that it’s actually a good idea to give big spending users like that “a seat at the table.”

Now, the problem with that is that you want to balance that out with important innovations coming from community members with “shallow pockets.” So called “community” people like to complain about monied interested invading the “community” as if big banks and telcos aren’t part of that community [NOTE: I accidentally omitted that magical "if" in my reply to John so it's not reflected in John's piece, which changes the point I'm saying here a bit, obviously] . I think what they’re really worried about is not excluding these people (“big companies”), but about money talking instead of useful, innovative ideas winning out, no matter how expensively dressed those ideas are. As long as board members’ decisions make sure to (a.) keep existing Java applications stable and working, and, (b.) advance the platform with new innovations as fast as possible they’ll be doing a good job. That’s how I’d rate any member, threadbare or sartorially sophisticated.

People seem to want JavaOne to be it’s own conference…

Yeah, JavaOne used to be the event for Java developers, and a significant one for the development world in general (we’ve seen Google I/O rising an interesting, if narrow replacement, kindasorta). Folding it into Oracle OpenWorld sends the wrong signal (Oracle is more important than Java: it wasn’t SunOne) and probably makes some Java people not want to attend. The Java world is much bigger than the Oracle world and it definitely deserves it’s own conference, if only in name.

“i” is for “integration”

I like this narrow focus on integration instead of just a general PaaS. It’s what you’d expect from MuleSoft’s background is in ESBs (Mule), Tomcat support (they seem to have built a new business around their “Tcat” server), and the open source world around the kind of tasks and applications (Java, mostly) you build around a bus.

Cloud Creep

I spoke with Ross Mason and Mahau Ma today, going over the announcement but mostly about the types of applications and work-loads they’re seeing people use in cloud-based projects. Some key take-aways:

• From the customer/user point of view, everything is wrapped up in iON. While it runs on a public cloud, the end-user interacts with the iON platform without needing to go muck with the underlying cloud.
• Last year, MuleSoft started providing Mule Cloud Connect (see an interview on the topic here) to help integrations between cloud and on-premise (and cloud-to-cloud, I guess). With all of the SaaSes out there (and Salesforce in particular, it seems), Ross said there’s been a big demand for integrating data between services. As he put in on the Mule blog a short while ago: “One of the drivers for Mule Cloud Connect was that we are seeing that traditional three-tiered application architecture is outmoded – Web applications today require integrating multiple data-sources and services, both in the cloud and behind the firewall, and presenting rich data to the browser in real-time.”
• This need for integration hits on something I’ve been starting to see: cloud-use is infectious in your architecture and even how you run your project. I’ve had a handful of conversations with people who’ve mentioned that once they use cloud for one part of their application (if only delivery), using it for more parts (all the way down to build and ALM) starts to look more attractive. To build on Ross’ comments from that blog: if you’re integrating your on-premise application with data in Salesforce, chances are good that you’ll start to wonder why you don’t move that on-premise thing into the cloud as well.
• As ever, Conway’s Law probably fits especially well here: you’d expect remote, distributed teams that are not centralized to build architectures that are equally “cloud-y.” For example, you could see how virtualized teams who work on cloud-deployed applications would really like moving all their version control to the cloud as well to places like GitHub.

And, indeed, that last point and the resulting transition is what Mule looks to be going after.

Disclosure: both MuleSoft and Salesforce are RedMonk clients, as is GitHub.

I talk with the press frequently. They thankfully whack down my ramblings into concise quotes. For those who prefer to see more, I try to dump publish slightly polished up conversations I have with press into this new category of posts: Press Pass.

Last week, John K. Waters asked me for input on NetBeans dropping support for Ruby. You can read his story from yesterday at Application Development Trends. Here’s the full response I sent to him:

I suspect that for Oracle, there simply wasn’t ample revenue or associated income from supporting ruby in NetBeans. Competition for ruby IDEs (or just editors) is tough, there’s a lot of them and many are free. Arguably, growing the ruby community helps Oracle grow the sales pie for MySQL (which they also now own), but I’m not sure that’d be big enough or a direct enough correlation for the money-minded Oracle decision makers. As the official note mentions, it’s a question of engineering resources (read: people either left, Oracle doesn’t want to provide budget, or both). And while Oracle says they’re happy for the community to carry on the torch, I doubt that will happen. IDE work is difficult, and requires much time and money, even if the final result is free.

Overall, this doesn’t mean much for the ruby and rails world. NetBeans was a nice tool, but it wasn’t the lynch-pin of success for that community. There’s a wide array of free and commercial tools out there that developers love using.

When this project started, long ago, it seemed to be part of Sun’s overall hopes that dynamic languages (ruby, python, and others) would help bring new developers and retain existing ones in the Java world. They wanted to motivate users of dynamic languages to use the Java virtual machine (VM) as a platform for their applications. Once Oracle took over, many of the developers and others on the “Dynamic Languages Dream Team” left the company, for whatever reasons.

RedMonk tends to see continues interest in rails, as well as ruby (see Stephen’s recent analysis of Hacker News language mentions for some stats drawn from one developer community). Still, languages like Java dominate the mainstream. Hosters like Heroku (now owned by Salesforce) and EngineYard (where the JRuby folks from Sun ended up at, if I recall) are finding much use for ruby and, thus, rails. There’s also much interest in running languages like Scala and other languages on-top of the Java VM.

Again, I suspect that for Oracle, the revenue from dynamic language support is less of a concern than from traditional, enterprise languages, like Java, and applications. Oracle hasn’t really been one to chase trends until they’re big money makers – see their CEO’s ongoing commentary on how “cloud is everything.” That seems to be working out very well for them.

Disclosure:

Salesforce.com is a client.

I keep getting asked about the impact of Oracle’s Java and open source world moves on the state of things in those two spaces. You may recall a previous pass pass from John K. Waters seeking comment on Doug Lea departing the JCP.

Innovation happens elsewhere

Recently, John K. Waters once again asked for comment on all this, I believe for this piece. Here’s what I replied:

Coupled with Oracle’s suing Google over Google’s kinda-sorta Java runtime, Dalvick, and the stink around the Hudson project trying to move and Oracle trying to prevent them, people should now know what the expect from Oracle. They’re a very commercial software company and will use – even get involved in – open source if it positively effects ORCL revenue.

Clearly, the idea of letting members of any given “community” do things that Oracle disagrees with is something Oracle wants to prevent. And, really, I don’t hold it against them as a business. They bought Sun as an asset and, no doubt, in their eyes the more open parts of that asset are, the less control Oracle has over them, and, thus, the lower the value of that asset…and future ability to pull out profit.

That said, the Apache Software Foundation has done a tremendous amount over the years to make the Java world a better place. The web server (which is not Java), sure, but the vast array projects that implement standards and the other libraries have brought millions, if not more, in revenue to the Java world: Struts, Tomcat, and so forth. And now, many of the important and interesting projects in the Java world are housed at the ASF – Hadoop and Casandra to name two Big Data examples. Java developers and companies owe a lot to the ASF.

If the ASF, its members, and the projects withdrawal from participating in the official Java process, it’ll push Java innovation further from the control of the standards bodies and its patrons. If more people take their toys and leave, as it were, the sanctioned Java world will have less fun toys to play with. I don’t think that threatens Oracle, IBM, SAP, or any other member of the official Java world very much in the here and now. But, it does mean that some key innovators – not all – will seek new places to evolve Java (see the Spring Framework as a historic example of this occurring). That could mean less control, ironically, for people like Oracle and more hassle when they want to catch-up with and incorporate those innovations if their customers start demanding them, and are willing to pay for such innovations.

A whole lot more

Recently, in my personal podcast, DrunkAndRetired.com (whose name should suggest to you the cursing and casual, amateurish nature there-in) I summarized the state of things and the (vague) impact I think Oracle’s moves (ASF leaving, trying to retain Hudson at java.net) is and will have. If you’re up for it, here’s about 40 minutes on the topic:

We also talk a tremendous amount about the business of enterprise software, enterprise IT, and developer relations as it relates to self-identifying (or not) with big companies like Oracle.

If you don’t want to sit here and watch the video above, you can download the audio directly, or subscribe to the podcast to get the audio.

That other guy is my old friend and DrunkAndRetired.com co-host, Charles Lowell, of The Frontside Software.

Disclosure: the ASF is a client, as is IBM, Cloudera, and VMWare.

CloudBees has purchased Stax Networks (see their write-up) to build out their ambitions to become the leading Java PaaS. Thus far, CloudBees has been known as the Hudson in the cloud company, running the continuous build tool in the cloud (on Amazon) for it’s beta users. Doing a build in the cloud is one thing, but tooling all of the activities around the build-test-deploy-run-repeat cycle is a bigger pie to eat from.

(As a minor note, by “Java PaaS” I mean “any VM-based language,” not just the Java language.)

Cloud ALM

There are many efforts underway to do “cloud ALM” though, wisely, no one calls it that. “ALM” has long been thought of as more of a bureaucratic-hell for developers than something useful. Still, for any sane organization the checks-and-balances and quality-through-process that ALM drives towards is required. It’s one thing for some slick .com to eschew ALM, but all those Toyota owners out there probably appreciate the mounds of process paperwork that ALM and higher paper-pushing practices stocked up.

As the diagram above shows, CloudBees is looking towards Stax to help them fill out the “deploy to production” part of that cloud ALM vision. I’d suggest that this “production” (the running of the code) is the area that needs the most innovation in the cloud space and is, therefore, the most difficult nut to crack. The idea of push button deployments to production is great, but the actual reality of deploying, diagnosing problems, rolling back, and so on get messy. And, indeed, solving those problems is (or should be) the value that a PaaS brings.

As a thought-experiment, I’d suggest that the ultimate PaaS would allow you to fire your entire ops team (as needed by the applications in that PaaS, at least) and just rely on the developers to run all that. Whether that’s a good idea or not is yet to be seen – I doubt developers want to strap a pager to their belt every night.

In essence, you need “fully automated provisioning” as some of the dev/ops crew would describe it.

It’s getting crowded

As a comparison, the Code2Cloud crew is tackling the problem from a tools perspective, where-as folks like CloudBees are going for an approach to build and own the entire ecosystem, not just service it. Another example: you can see this general idea being worked out in the mobile space by PhoneGap/build. I come across “build in the cloud” folks all the time now-a-days, and I expect to see even more of vendors moving the entire software development and deployment tool-chain into a cloud – if only “cloud-like” (CloudBees said they have an on-premise version for the weak-kneed) – environment.

More

• Announcement page from CloudBees and, also, Post from CloudBees’ Sacha Labourey on the topic, including: “Stax Networks was the first company to deliver a full fledge Java PaaS back in 2008. Since then, more than 3’000 applications have been deployed to it, with some customers such as Lose It! running more than 5’000 transactions a minute on it.”
• Paul Krill reports on the announcement for IDG.
• Coverage from Scott Kirsner on November 29th, 2010 of CloudBees’ $4M funding and plans.

Disclosure: CloudBees, TaskTop, and VMWare are clients.

John K. Waters had several questions about the cracks du jour in the until recently sleepy and happy Java community:

What’s up with the JCP?

First, John asked about Doug Lea leaving the JCP, to which I replied:

I don’t know Doug Lea personally, or professionally really. While I haven’t spoken with Oracle on the topic, they do seem to be changing how the Java community is being run, making sure to control as much of it as possible. Really, I don’t know why we’d expect less: Sun tried to exert control (and in befuddling the ASF around TCK and “field of use” fine-print tactics acted like a pretty poor community overlord, despite the massive goodness that came from other efforts like OpenJDK), and Oracle spent a lot of money buying JAVA.

Oracle’s business model is to buy large, successful cash cows and milk revenue from them as much as possible, and what you’re seeing around their mum approach to the Java community aligns with that. More than likely, they’ll only get “involved” when the ROI can be quantified (a number that can put in a spreadsheet cell), not just when it’s a “good thing” or several steps removed from revenue generation. Sun’s business practices around open source were somewhat the opposite, which didn’t work out well for them in the long run at a corporate level. So you can imagine the new owner of JAVA feel justified in changing the way it operates.

What that means is that Oracle would (I’m guessing) like to see the Java community become more commercial, rather than “academic.” In contemporary standards bodies like the JCP, this means emphasizing the business value of a standard or effort, even at the Java SE level, meaning people like Doug Lea, as he explained very well in his letter, don’t really have a place in the JCP. It also means standards body knife-fighting and “back-room” politicking which is probably odious to most “open” minded people.

It’s like all those reality TV shows where everyone says one thing: “I’m here to win, not make friends.” Hopefully Oracle’ll listen to the gentle nudging in the community to win by making friends instead of ignoring them.

Apple Dumps Java

As of the release of Java for Mac OS X 10.6 Update 3, the Java runtime ported by Apple and that ships with Mac OS X is deprecated. Developers should not rely on the Apple-supplied Java runtime being present in future versions of Mac OS X.

–Java for Mac OS X 10.6 Update 3 and 10.5 Update 8 Release Notes

John then asked about Apple’s decision to “deprecate” Java on OS X, that is, stop working on the Java runtime they’ve been delivering for years now.

Again, not having spoken with Apple on it, I just have pure speculation.

Apple has become the massively valued company it is by building a closed stack under its control. Consumers so far seem to love them for it. Java is outside of their control and consumes resources to get “perfect” enough to run on OS X.

The desktop hasn’t been a top strategy for Apple, iPods and then iPhones and now iPads being the chief strategy. But, with their new interest, it seems, in growing Mac desktop market-share and, more importantly, their ambitions to replication the iTunes App Store on the desktop, logic would dictate that Apple needs to lock down desktop development more. My theory is that Apple sees the Mac App Store as good bet for more revenues (more from selling more hardware than that cut of app sales, as with iOS devices), and wants to control as much of that stack as possible. Java is way out of their control, so under that strategy it’s got to go.

It’s also a wicked way to cause trouble to other ISVs. While Java on the desktop may not be used for a huge amount of desktop applications on OS X, it is used to back most of the development tools, esp. Eclipse. Developers have flocked to the Mac as a their primary computer and development machine. Without a good, frequently updated Java runtime on the Mac, all those developers will be in trouble. To play the grandpa role, back when I still wrote software, even when there was official Java support from Apple, the lagging release cycle meant Java developers on the Mac were always several months behind – it was crappy.

It’s not really that dire just yet, but it’s certainly annoying for developers and the companies putting out Java-based developer tools who’ll have to use other methods than the (now dead) “official” process for getting Java. It creates a great opportunity for someone to come in and play good cop to Apple’s jerk-move here, as strategic as it may be viz. the Mac App Store.

Disclosure: The Eclipse Foundation is a client, as is the Apache Software Foundation and other people who care about the Java world.

Just flying back from Adobe MAX 2010 I’m coming away with the sense that Adobe has finally realized the value of the web over Flash, giving them a fighting chance where once they seemed a little too “let them eat cake.” It’s a few more long days of marching to get out of the woods, but they’re at least pointing in the right direction…finally.

Still not dead yet

Adobe has suffered from three things of late, only the second two of which I and you, dear readers, really care about:

1. Poor Creative Suite 4 sales and/or sentiment – why upgrade? We just buy every other version anyhow.
2. Apple hates Adobe & delights in kicking sand in their face in front of the ladies. Everyone left Apple for dead (aside from that weird $150 million Microsoft injection aside back in 1997), and now Apple’s back like an angry beefcake with a well cut 2×4 ready to bludgeon Everyone into a shallow grave.
3. Too rabid of a belief in Flash as a development platform, and the strategy and portfolio neglect that came with ravishing attention & affection on Number One Son.

After this week’s MAX, Adobe seems to have removed of enough of this chaff – not all – to start taking control of their own destiny and start having a real tools strategy beyond “skip intro” that can could grow into one of their future cash cows, web & app development.

Beyond Flash

Several years ago, at MAX 2006 my take away from the gold-encrusted halls of the Venetian was that Adobe was trying to fork the web with its Flash ambitions. Their line, the Macromedia injection still fresh, was that it was a better platform than the stagnated and hard to develop web technologies available (Ajax at the time). Of course, it was Apple and Facebook who succeeded at forking the web, each in their own wickedly clever and bold ways. In retrospect, Adobe never stood a chance against those dynamos.

After years of keeping web development in the closet, from the Adobe MAX keynotes and news this week, it seems like Adobe is now leading their conversation with web, and with the charged Rorschach-semantic inducing “HTML5″ at that. (The only tech-term that’s less precise and more vaguely all encompassing than “HTML5″ now is “cloud,” “SOA” having been exiled off to the old folks home long ago.)

If you look into their eyes, you can pretty much believe that these Adobe folks really mean it when it comes to servicing web developers, not just Flash developers. Their technology is both ancient and early. You may have forgotten the Dreamweaver and ColdFusion empires Adobe has in recently, Flashier times; their “HTML5″ tools – like all of HTML5! – are a work in progress.

What’s Required

As James Governor said in one of our meetings, Adobe’s success in the web development market requires violating one of the top Adobe marketing taboos: breaking up Creative Suite bundling, if only for the web development tools products. More than doing that (which, to be fair is done somewhat across Dreamweaver, Flash Builder, and Coldfusion – keep it up!), pricing will be a tough nut to crack. Web developers pay more for coffee in a year than they do for tools, and even the price of the lowest level of Creative Suite will keep developers in the black stuff for months.

To crack the web developer market, Adobe has to move into the $50-$100 price range that TextMate and (lower rung) IntelliJ tools swim in – IntelliJ lets you spend more money if you decide you’re not a “student” in the school of life. It’s a miracle that those two pervasive tools can pry cash out of skinflint developers, and they’re clearly setting the pricing bar. If Adobe could figure out monetizing cloud-based services (Cf. Code2Cloud or Adobe’s own BrowserLabs), then the numbers might work for free tooling, but Adobe just doesn’t seem ready for that in the short term, despite the sleeping giant that is Adobe’s SaaS portfolio. (Said giant’s slumber is a constant source of befuddlement for me.)

It goes without saying that the tooling has to be “agnostic,” working with whatever web, HTML5, Ajax, mobile, etc. technologies that come out, treating Flash as a feature (as James put it, I believe) rather than the platform. So far, this “new Adobe” hasn’t done anything to make me think they won’t, but it’s a shaky sentiment.

An Excess of Opportunities

Given that Apple isn’t thought to be slashing at Adobe’s sinews anymore, when it comes to platforms and development, Adobe actually has several great opportunities.

Day

Adobe has an under-appreciated (by The Market) asset in Day software (once the acquisition closes, blah, blah) which brings them an overly goodwill-encrusted seat at the open source, and thus, developer relations table. While Day may not be widely known as a brand to all, their deep tie-up with the Apache Software Foundation and the Java community is critical, valuable, and real. Adobe hasn’t always maximized how they use open source tactically, so the developer relations energy that Day brings is Adobe’s to loose, or use.

Java

Pulling back, the fragmentation in the Java market and Oracle’s “I’m not here to make friends” attitude is creating developer relations vacuums right and left in the Java world at the moment. VMWare/SpringSource are inches away from filling those holes, but there’s still time for others. And while “Java” may seem like the antithesis of what Adobe would be interested in, the question is: how many other technology ecosystems are out there? There’s such a small pool of them at the moment (Java, PHP, “web,” iOS, and mobile…see below for “tablet”) that it’s bad risk management to ignore any of them.

JavaScript

There’s a huge opportunity for Adobe as well that hedges especially nice against all their developer-world risks – a quick review of those risks: failure of the market to break iOS hegemony; Adobe’s failure to make friends with at least the Java and “web” communities; and the Flash Player going the way of the Real Player. That huge opportunity is JavaScript. While Adobe doesn’t like to utter the phrase “JavaScript,” when it comes to ActionScript/ECMAScript/JavaScript/WhateverYouWantToCallItScript, Adobe has some of the fattest brains in the industry (next to Google, Facebook, I’d think, and the rag-tag mega-successes like node.js and jQuery). While JavaScript is far from a mainstream developer “trend,” it’s certainly on the projectory, and no elder company is providing the adult supervision that leads to market funnel magic and cash-cow stability. Adobe is one of the few companies that could legitimately do that, but it’d take swallowing a lot of pride, weirdly.

“Our people are our most valuable assets.”

And that’s Adobe’s lowest hanging fruit when it comes to this: letting their engineering out of the house. Adobe has done a poor job of having their developers talk to the developers they sell to. Don’t get me wrong, it happens, but it’s a far cry from the salad days of IBM developerWorks and the (sadly revenue-disconnected) developer relations success Sun had around Java. The web would be a more exciting place, and more favorable for Adobe, if their Computer Scientists were given carte blanche to talk to the outside world and given incentives too. The more outrageously frank and transparent the better – e.g., James Gosling has done a suburb job in developer relations for the Java community now that he doesn’t actually work for Snorkle.

(I should say: I have no reason to believe one way or the other if Adobe engineering is “locked up,” but they certainly could be pushed to be more chatty in public.)

The Great “Multi-screen” Bet

I discovered on this trip that I have no idea what “multi-screen” really means, in the same way that I have no idea what “HTML5,” “cloud,” or “SOA” really means anymore. “Multi-screen” means a lot of things, and a lot of fun and interesting things at that (queue the Minority Report mouth-breathers).

Adobe uses the term to mean the new market Apple has created in smart phones and tablets, and also the emerging TV-as-computer market (“computer TVs”?). Apple has this market locked up now, and as one spot-on commentator recently said (can’t find the link, tragically), whenever you hear the word “tablet” now, people really just mean “iPad.” The “tablet” market does not exist in any real way…yet.

We’ve seen devices like the Samsung Galaxy, the Blackberry PlayBook (which I’ve learned that James has a love affair with), and even the actually shipping Dell Streak. These devices are “dropping,” as the kids say, sometime soon, just in time for Christmas, the Festival of Light, and other excuses to spend gads of money on China’s best. This “holiday season” is D-Day for the tablet space. If the invasion succeeds, people like Adobe (and, really, everyone else but Apple) will be a good position. If it fails, the ground hog will have seen it’s shadow and it’ll be more of an Eastern front meat-grinder than an adventure in France.

TV is an odd port of hope here – a sort of Casablanca to continue the pained metaphors – where no one really has much control (read: Apple). With Netflix OnDemand and Hulu shipping in TV-as-computers, the civilian consumers of the world actually have a reason to buy these products (unlike the tragic Bluray forays Sun tried to make several years ago, which was structurally the same TV strategy Adobe and others are now making). Would be TV-as-computer arms dealers like Adobe need to start showing people why they’d care to have “widgets” on their TV beyond streaming video. I’m not sure DVD menus have been a “must have” for consumers (they seem to get in the way of actually playing the video and those extras are usually adver-crap you’d expect to see on the TV Guide channel), but that’s a glimpse of what could be done. More interestingly, as James pointed out, is the ability to “drill down” on various things on TV, like the stats for some sports player.

As mentioned above, for Adobe (and others), hedging against the huge risks (read: Apple + 2×4 + shallow grave) in the “multi-screen” space is key. No tech company can afford to put it’s eggs in one basket here (except for Google who has more eggs than they know what to do with), so they need to look towards desktop and traditional web and mobile development as well. “Tablet” is no easy street just yet.

Merger Mania

It’s popular now to speculate about technology company mergers. I will briefly indulge you, dear readers, because RedMonk Analytics indicates you like it and if anything, we aim to please.

In summary, after the long-winter of not spending money, technology companies have massive cash balances on their sheets and pundits are eager to see them spend it (I’d prefer the more grinning-Machiavellian strategy that Google can pull off: wait for another nuclear winter and use your cash-piles to out-spend, out-hire, and out-price [free!] the innovation-skeletons who’re your competitors, but Wall Street can’t be bothered to think for more than 90 days into the future, so never mind that).

Since the Microsoft and Adobe CEOs met, everyone is abuzz about someone buying Adobe. First, it’d be crazy for Microsoft to buy them – but, hey, Oracle bought Sun, so one has to be careful about what’s considered mental illness, the desk reference apparently under new editorship. I’m not a numbers guy, as you know, dear readers, so I have no head for putting together the spreadsheet to make sense of these things, but when has that stopped me? I have two picks for the parlor game du jour:

• VMWare/SpringSource – whether by strong partnering, merging, or acquiring, these two together would put together the foundation for a solid, new developer ecosystem and platform. VMWare needs to figure out application development to retain and up-sell to it’s existing customers and to bring in new customers; SpringSource needs a killer-UI strategy, and their mobile story is anemic at best (and they’ll admit this, with a quick, trustworthy follow-up of “we’re working on it”). The difficulty with this is all that other stuff, you know, that makes all of Adobe’s money, Photoshop, publishing, video. But, hey, it’d be good on EMC/VMWare if they boggled The Market’s minds again (the first time being SpringSource) and just said, “hey, consumerization of IT, bro!”
• Google – these guys can’t do product strategy to save their life, and they have no reason why they should, because their life is in no way under threat. If Android and every Google UI was even half as well done as Apple user experience, Google would quickly move into that tasty monopoly territory Microsoft milked until they hit the government ceiling. Adobe could bring that in the web, desktop, and mobile space. Think about how critical Flash was and still is to YouTube and how big a part of Google’s identity that is. Google UX and UI are bad, but the functionality is so good we don’t even notice. Part of Apple’s disruptive success has been taking the time to deliver over-the-top UX and UI, and adding Adobe to Google would be like gas on the fire.

I don’t really seriously think anyone Big would acquire Adobe, or vice-versa. As I say, their business is such a hodgepodge that it’d be weird to buy and then run all of it. Then again, companies like HP do well with a mix of printer ink (!) and blades.

More realistic is to think about partnerships like the above.

RIA is Dead

Nothing like a little link-bating, eh? Seriously though, I’ve had the personal sentiment, half-jokingly uttered to many of you, dear readers, that the term “Rich Internet Application” has run its course. You don’t hear the “RIA” term used as a general term, outside of the cadre of folks like myself. I’d expect Adobe to be the big boy on the block still using the term, but, really, they don’t. I’m sure it was uttered many times in public, during keynotes, but I didn’t really notice. In private conversations, sure, the term was used, but it was more for lack of a better phrase.

It seems the phrase RIA just isn’t taken seriously by people anymore, let alone used at all. The technology, ideas, and goals are all the same, but RIA as a distinct thing has been subsumed into what it is to be an application or a mobile app. Of course the UI has to look good, be “rich,” and of course it’s going to be connected to the Internet. An app that doesn’t do that is just text messaging.

As I’ve noted in snarky Twitter comments here and there, SOA has long been in the same boat. No one would dare say they’ve built an SOA for all this mobile, social and Whatnot 2.0 stuff, but that’s exactly the type of backend – architecture – that has been built out. Just like SOA, the idea of RIA is a strong as ever and widely in use.

What pushed me over the edge to finally tuck “RIA” into bed was the fact that multiple people, Adobe and non-Adobe, said as much themselves in private conversations. So much so, in fact, that I now feel like I’m a bit of a pass thru for The Message, really.

Disclosure: Adobe is a client and paid my travel, hotel, registration, and plenty of food & drink for MAX. I got a free Droid 2 (no service, though) and Logitech Revue Google TV, as did all the MAX attendees. Microsoft, Dell, VMWare, the ASF, and TaskTop are clients as well. Day was a client. See the RedMonk client list for others.

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.

(For an excellent, detailed summary, see Darryl Taft’s write-up of day one and then day two.)

Code2Cloud

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.

(“Send moar minis” from Christopher Blizzard)

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.

Google Partnership

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. As Oracle’s William Vambenepe recently showed, the management piece of a PaaS is an extremely complex and demanding set of functionality: you can’t just expect people to sort out diagnosing cloud-based applications on their own, they’ll need tools that are designed to work with that platform. They need a Wily for the cloud, which is what this tie-up is going for: doing end-to-end tracing of a request from glass to metal, from front-end (if it’s Chrome) to database.

The demos are compelling, but, of course, limited to the Spring stack.

The third announcement ties much of this together and gives you some tea leaves. Hidden in the messaging around the “SpringSource Tool Suite and Google Plugin for Eclipse” is the fact that the Spring Framework is essentially being “certified” (thought they don’t call it that) to run on Google AppEngine. AppEngine has long been a weird-beast of Java: it has a whitelist of classes that will work and support, which is a fancy way of saying it’s not 100% Java compatible. Having Spring, more or less, “certified” to run on AppEngine means developers can worry a little less about that weirdness…if they develop on Spring.

At that point, tying in the ETE monitoring that Spring Insight and Speed Tracer brings you makes sense – it’s part of that stack.

For VMWare, this is another cloud partner that Spring is paving the path for. SalesForce, of course, is the other prominent one. It’s interesting to watch the “use Spring as PaaS interop” as part of VMWare’s cloud strategy, and I’d expect to see more such moves as they try to get their tendrils into as many “clouds” as possible. In a post open source world (pardon the phrase), it’s worth thinking on the question: if your code runs on most of the (proprietary clouds), does that mean it’s interoperable, or lock-in madness? The answer is a little less clear than you’d think if you grew up in the era of rainbows and sandals (like this guy did, dear readers).

It’ll certainly roil up the usual Java suspects, esp. those who have their own cloud agenda to push (mostly RedHat and IBM, and Oracle if you slap in their “cloud is everything, so, yes, we’re doing cloud” world-view).

The New SDKs: Social, Mobile, Big Data

Next up, SpringSource started tossing out some vision in a rare escape from the highly technical (and welcome) content they usually put out at SpringOne. Rod Johnson and others pointed out that “social” and “mobile” are two huge areas of interest looming in the future (and in the here and now if you’re lucky to work on it). They’ve been hammering away at projects in both spaces, represented by their running reference application, Greenhouse.

Here, the pivot you need to make is thinking about all those social networking sites and services (from Facebook to LinkedIn to Twitter) as “the new APIs” that the Spring Framework will wrap. That’s been Spring’s thing since the beginning: finding the APIs (and, implicitly, the actual running code underneath the interfaces) that are popular and powerful, but terrible to actually use – J2EE, for example. Then take wrap those APIs in the Spring to make them easier to use. From that, the rest of the Spring empire was built.

Now, there’s less action in the framework and API world than their used to be. There’s still plenty for sure – but the real interesting action are in the APIs that social services host: the Twitter API, Facebook connect. These aren’t things that will show up as an open source project somewhere, they just exist as the one API in the cloud.

For SpringSource, then, the shift is to treat those hosted APIs the same as they did J2EE, and try to figure out how to integrate them into (corporate, mostly) Java developers’ work.

Mobile is another form factor, another UI. The thick-client model mobile encourages seems to be having some interesting effects on the old MVC monopoly, and once you throw in JavaScript as first class citizen (something SpringSource hasn’t done yet), things do start to look different.

And, then there’s NoSQL, which means to SpringSource, as Rod Johnson said, “We mean ‘Not Only SQL.’” Their GemFire buy gets them into some credible discussion here, as does the work with neo4j. RedMonk has been field many inquiries about using NoSQL, so I can’t help but agree with the sentiment I heard several times from SpringSource folks that now is the time to start sorting out when to use Not Only SQL.

Disclosure: VMWare is a client, and paid air and hotel for this trip. TaskTop is a client as well. IBM, RedHat, and Neo Technology are clients as well. As always, see the RedMonk client list for others in this space.