Everyone is gaga for the cloud, but how exactly can you get your stuff up there? A local, Austin-based company is trying to crack that problem. Here’s what’s in vConstruct’s stack:

Who are you?

vConstruct helps companies migrate to and adopt cloud based technologies by providing tools and services. Our new product, MigrationPath, helps professional service organizations migrate their clients to the cloud, helps SaaS companies onboard new customers, and helps individual companies migrate their data to the cloud. My name is Art and I am VP Technology for vConstruct. I recently moved to Austin from Philadelphia at the end of March 2011.

How would you describe your development process?

We are a small, agile development team and we are currently working on 1 week iterations. We plan and create/estimate our tasks as a group, then we develop, test, and release. Right now we manage our development processes using Google spreadsheets, but we are currently evaluating more sophisticated tools. Once our iteration is complete, we deploy to a local server for testing, and then deploy to Amazon once testing is complete.

What tools are you using?

We use Visual Studio for development. Our product lives in the Amazon EC2 cloud, and our product can be deployed using simple XCOPY deployment. We wrote our own .NET deployment tool to copy the files up to Amazon. We also use the same deployment tool to deploy to our local server for testing.

A tool you’ve used recently that didn’t work out well?

We tried to use Rally Software to manage our development process. The tool had everything that we wanted, but it got very slow and clunky as more stories and iterations were added. We finally decided that it was too much of a hassle to use Rally and switched to Google docs. Definitely not the ideal solution, but our team is small enough that it works ok for us.

Anything else?

We are actively seeking developers, in particular a web application (UI) developer. Our job description is available on vconstruct.com/jobs. Follow us on twitter at @vConstruct. [Also, see their launch press release.]

With the rise in popularity of Jenkins/Hudson, I’ve been wondering what happened with Cruise Control, the break-through project that helped bring continuous integration to programming. Charles Lowell of The Frontside tells us his theory.

In addition to viewing the video above, you can download it directly or subscribe to the make all podcast feed to get it automatically downloaded.

Transcript

As usual with these un-sponsored episodes, I haven’t spent time to clean up the transcript. If you see us saying something crazy, check the original audio first.

Michael Coté: So Charles, Jenkins very popularly used to be called Hudson.

Charles Lowell: Great!

Michael Coté: And yet there was CruiseControl. Why — I don’t want to say failed, but why — how did Jenkins, how was the space created that Jenkins took over from CruiseControl?

Charles Lowell: Well, let me start by answering the question with two words or talk two words but with one sentence, and then go on to expound for, I think, but you got your answer already. I think this thing just works when you like install it. You can download Jenkins and you’re up and running in about thirty seconds, whereas CruiseControl never was that. It was always a pain in the ass to get up and configure and blah, blah, blah and, I mean, I lost track of it.

But certainly while I was at ThoughtWorks, it started out as an ENDscript and a con job, right, and kind of snowballed from there and it was never kind of brought around from project to project and there was kind of good contributions from each place but it wasn’t ever — at least in my experience, a coherent project so much as an idea. And there were bunch of implementations on that idea.

And the thing is this, because it was for the people, it owned it, and in this case I’m thinking ThoughtWorks and ThoughtWorkers, it pretty much worked on –

Michael Coté: Quite a lot of extra –

Charles Lowell: I mean pretty much work but they were familiar with that. So setting it up on — at the beginning of each project wasn’t a lot of overhead in a grand scheme of things. It’s a couple three days or something, but you’ve done it a bunch and — so there’s no need to invest and package it so that it’s — so that it’s –

Michael Coté: So it wasn’t sort of like a product.

Charles Lowell: — that’s; yeah, it was never a product. I mean there was trend — it was, like you said, they were rumblings now making into a product, but I think that it was definitely more of an idea, and a very successful idea that was thought.

Michael Coté: Oh, yeah, yeah. That was — if I remember, it was, if I may use the word, it was kind of revolutionary in that sense, it was like oh, continuous integration.

Charles Lowell: Right.

Michael Coté: Huh.

Charles Lowell: Right. And so I guess that’s –

Michael Coté: And it just never evolved beyond that.

Charles Lowell: It never evolved into –

Michael Coté: — beyond a collection of scripts, as we would say, in the IT management world. There’s this distinction between, you’d get a bunch of products to monitor things, and it’s just a bunch of scripts. And then at some point, those scripts turn into a product.

Charles Lowell: Right.

Michael Coté: And I guess CruiseControl was sort of a downloadable thing that you could get up and running, but what you’re saying is it just didn’t get polished as well as later on, and then Hudson, then later we name Jenkins came in, and sort of polished this up.

Charles Lowell: And up and without having anything to build or anything knowing how to build it, you just –

Michael Coté: And there’s lots of other continuous integration tools out there, but that’s the one that you prefer.

Charles Lowell: It’s very — it’s pretty much to me just; can I use another buzzword “Zero Configuration”?

Michael Coté: Oh, yeah. Yeah.

Charles Lowell: You don’t have to configure a database.

Michael Coté: Did you know that?

Charles Lowell: — no dependencies; in the simplest case, there’s no dependencies, no configurations.

Michael Coté: Yeah. I think — did you know that Apple’s Bonjour thing was supposed to be called Zeroconf I think. But I think someone had a trademark on it so they couldn’t call it that.

Charles Lowell: Oh, is that what it is?

Michael Coté: — or something like that.

Charles Lowell: I thought Bonjour was Apple’s implementation of Zeroconf.

Michael Coté: Who knows.

Charles Lowell: Who knows.

Michael Coté: Bonjour!

Charles Lowell: Good evening!

Michael Coté: Well, thanks for the history lesson, Charles.

Charles Lowell: Yeah.

Why pitching development tools as “making you more productive” doesn’t work as well as you’d think.

Developers don’t care about money – in the same way doctor’s don’t care about money. That is, they actually do care about their personal income, but don’t like to admit it, and are not always motivated to think about the company’s income. Business owners and manager care about money. At small companies, they may be the same, but for many shops (at companies and ISV) across the medium and “enterprise” spectrum, they’re not.

This means that discussions about “productivity,” as in saves and/or makes the company more money, are often not useful conversations to have with developers.

The success of Eclipse Mylyn, TaskTop, tools from Atlassian, and Agile are interesting exception here. Each of those may contribute to the overall success of the company employing the developers, but they mostly increase the ease at which developers can do their own job, irrespective of how profitable that ease becomes. Something like Mylyn makes working on a bug or feature less boring and tedious because all of the relevant context is presented to the developers: it also isolates the developer from the “productivity” tools the rest of the company uses (the way TaskTop 2.0 layers on-top of and hides all the ugliness of wonky, never-gonna-be-replace ALM back-ends is a good example here as well). Chances are, whatever project management, issue, and bug tracking systems and process a company is using, developer loath it. They want to stay in their IDE, coding.

Agile is successful, at the developer level, because it seems to empower developers and make their lives easier. It gives them a tool to talk to the rest of the organization through in terms that work, helping developers do expectation management (not overselling their abilities and then suffering when they have to deliver on unrealistic goals). Much of the excitement you see in developers eyes when they’re exposed to dev/ops comes from a similar function: finally, a way to see what their software is doing in production without involving mind-numbing conversations with “IT.” (I like to think of these types of phenomena as The Developer Landgrab.)

Whether using Agile makes a company more or less money is irrelevant to a developer: what matters (as with all “productivity” tools) is if it makes the developer’s life easy and allows them to block out (or, at best “manage”) the non-developers in the rest of the company. Developers don’t want to be made productive, they want to be empowered.

Disclosure: TaskTop is a client.

Technologically, VMWare is interested in seeing wider Java-based application development, esp. in the “line of business” area that the easier to use WaveMaker tool targets. As I so often quip, you don’t hear about Rapid Application Development (RAD) anymore, but the need for tools that allow more junior (or just cheaper) programmers to create applications hasn’t ever gone away. I discussed this with Chirs Keene last fall in this RedMonk interview:

More forward looking, WaveMaker is a good fit for a PaaS, having a sort of wiki approach to applications running in the cloud. As Rod Johnson says, “WaveMaker as a service will fit naturally with our cloud computing strategy, including Code2Cloud.”

Related to this is the recently announced Eclipse Orion project which is seeking to make an in-browser IDE. So far, it’s looking interesting – check out this webinar from a few days ago. And, of course, Bespin/Skywriter has had a lot of interest historically in this space.

More

• VMWare’s Rod Johnson outlines the reasoning behind the purchase.
• WaveMaker’s Chris Keene’s blog post on the topic.

Disclosure: VMWare and WaveMaker are clients, as is the Eclipse Foundation.

What are developers interested in when selecting a Platform-as-a-Service? If there’s ready cash at hand, lock-in and “proprietary” is demoted in favor of a quick buck; if the developers are building a general application with a longer time between compile and cash, an open, standard platform is more attractive. That’s the quick take, at least.

We’ve been having discussion more discussions about PaaS dynamics at RedMonk of late as people look at PaaS options (both selling and using). Here, I summarize:

1. The more popular and curious PaaSes
2. Why looking at PaaS is valuable for vendors
3. How RedMonk is starting to see developers evaluate options, early in this field as it is

The PaaSes in Hand

(Above: interview with Issac Roth, CEO of PaaS provider Makara, now owned by RedHat.)

There’s not enough data and (more importantly) history available to make generalizations about broader PaaS adoption. Nonetheless, there’s actually a hefty handful of PaaSes out there:

• Salesforce.com’s Force.com has been around awhile with “more than 150,000 apps” as of April 2010.
• Other Vertical PaaSes like Intuit’s Partner Platform have had a PaaS in their space (here, billing and accounting, pretty important for most businesses).
• Google App Engine – several folks told me there’s around 150,000 apps in there too. Oddly, we don’t hear much about developers using App Engine – totally unscientific and anecdotal, of course.
• Microsoft Azure with over 10,000 “customers” as of June, 2010 – listen at about 2:17 in this recording. Like App Engine, I don’t hear a lot about Azure use from folks I talk with.
• Heroku comes up a lot (100,000+ apps when acquired by Salesforce).
• There’s been several new PaaSes of late: such as CloudBees, VMWare/Spring’s ambitions (e.g., VMforce), RedHat/Makara, and even a node.js service. Also, offerings like Joyent’s SmartPlatform have rolled older hosters into new models

Arguably, Amazon has been offering so many pieces of middleware that they have a “build your own PaaS” stack (a sort of “salad bar”), but I won’t consider them for now. (I haven’t had a chance to check out AWS Beanstalk yet, here’s some early commentary in Quora).

There’s numerous PaaSes I’m leaving out (like Bungee and Morph, probably, and it looks like Oracle has something running around – many of them are collected in my bookmarks) – feel free to add them in the comments below – I’d appreciate it, actually. (E.g., here’s a quick answer by Tweet.)

Why start a PaaS?

Software vendors (esp. middleware vendors) are wise to start figuring out how they can exist in a cloud world, and a Platform-as-a-Service is an attractive option for such vendors for several reasons:

1. It’s available – Getting into the IaaS business is very difficult now, capital intensive, and establishing the differentiation (from Amazon, Rackspace, and others) needed to succeed is difficult. Ultimately, developers want to write applications, not manage cloud infrastructure. As Stephen noted in his predictions piece, while PaaS wasn’t a hot topic in 2010, because of that it’s a huge white space for vendors to get into.
2. It’s what you have – The middleware and application development stack is often what vendors have in spades, so naturally, you want to roll what you have into your future.
3. It’s billable – People will pay to run otherwise free software. Many vendors over the last decade have had to release their middleware and stacks as open source – developers would use little else. Monetizing open source (aside from getting a big company to buy you) in terms that investors want can be difficult. How much “support” and “integration” does the world need for something that they can download for free? Clearly, a fair amount to hear about the revenues and engagements of our clients, but there’s still money on the table if you can wangle how to snatch it. The acceptance of a metered payment method for software (cloud, PaaS, etc.) is a huge hole in the open source company revenue ceiling: it’s way to get people to pay for free software…in theory.
4. Up-sells, market-segmentation – Heroku and AWS provide good examples of the up-sell options for PaaSes. The basic service may be cheap, even not terribly profitable. But because of the ease of integration and speed to purchase, layering in additional services at a cost (of course) is an attractive model. It makes for excellent partner programs as well (read: little effort on the PaaS provider’s part as the partner does most of the work, with a percentage on sales). The potential partner ecosystem for PaaSes (and all cloud-based services, actually) seems like it’d be excellent. You can see where these ad-ons allow you to segment the market as well. It’s not clear that the usual dynamics work the same (slapping the word “enterprise” or “essentials” on something), but the segmenting minded out there should be drooling over the possibilities.

Evaluating PaaSes

(Above: no-PaaS vs. PaaS slide from Microsoft’s PDC 2010.)

All of that context in the chute, here are some observations:

1. Quick cash trumps all – while platforms like Force.com and IPP are not general development platforms, the fact that they bring large, ready customer bases makes them attractive for developers who want to write “quick” plugins and extensions to that platform. If there is a ready market, lock-in concerns are less of a priority. The iTunes App Store, while not a PaaS, is another touch point of otherwise lockin paranoid developers going after the gold instead of the long-term flexibility of an open ecosystem.
2. A ready customer base – for providers like Salesforce, the customer base, customer data, and customer process is an incredibly valuable asset. It’s a market to sell to and “eyeballs” to get in front of that most developers and small teams would be at pains to access. Similar effects are being seen in marketplaces like the Google Apps Marketplace: back in October 2010, RedMonk client MindQuilt said they boosted their trial customer sign-up by 15% when they were featured in the Google Apps Marketplace. Also, check out Bob Warfield’s commentary on the wider value of data for the PaaS vendor.
3. For applications, open is desired – if a developer is working on a general application (the type of things an ISV would traditionally work on, software to sell) the desire for an open platform are high. Much of the fear of lock-in and proprietary technology use comes from the fear that potential business models and revenue will be cut off by that lock-in; or that the technology locked into will hinder future development and cash-flow. A PaaS like Heroku shows the general appeal: while there’s a certain degree of lock-in (having to re-create the stack provided by Heroku and come up with a new deployment process and home, etc.) most of the services offered are standard open source ones. Even if they’re not open, like the Apigee add-on, most components can be rebuilt in another platform.
4. Speed, hassle reduction – for developers, as Heroku has shown, the speed and ease of development and deployment are very attractive reasons to use a PaaS. Developers are giving up the ability to completely customize their stack from the metal up (OS, runtime environment, frameworks, etc.) – they’re giving up the joy of tinkering. In trade, though, a PaaS should make their lives easier: using a PaaS should be much less of a hassle than deploying your own application stack, even on an IaaS provider. (William Vambenepe, as always, has a pragmatic look at the idea that you won’t have to worry about that gorpy stuff anymore in PaaS-land.)
5. Identity and single sign-on – as Facebook Connect and Google ID become more ubiquitous, developers can skip the messy, tedious, and low-value identity sub-systems in their applications. This is an weird, risky piece of lock-in (remember how upset the world was about Microsoft Hailstorm?), but using those identity systems to bootstrap in user’s identities is becoming more widely acceptable.
6. Scaling – scaling up (to meet demand) and down (to control costs) was one of the original promises of cloud computing. For those developers looking to provide widely used, public web, mostly consumer services, building in scaling is a solid requirement (while all of the popular consumer services fall down, they tend to get back up quickly, and they don’t stumble as much as you’d expect). For others (those targeting small scale user bases at much higher per-head price), scaling may not matter a tremendous amount.
7. Cost – the original promise of cloud computing was cheapness. Just as with “free” open source in the days of yore, this can mean different things to different people (read: not as cheap as you originally were lead to believe). The idea of paying metered costs – paying for what you need – is an equally attractive option for development teams that are starting out. As numerous Y Combinator Cultists will say, it costs “nothing” to actually start a software-based venture now because you don’t need to lay out a bunch of cash for equipment ahead of time. Once you’re successful (read: have money either from paying customers or for investors based on a large enough “free” user-base), paying for better infrastructure isn’t so much of a problem. It’s that boot-strapping that matters, and a PaaS that allows for paying very little are attractive. For PaaS providers: consider only making developers pay for the service when it’s in “production” rather than development and testing.

Of course, there are management considerations for using a PaaS as well (optimizing and making better the delivery and use of IT by the business to make money, the pitch goes, as it goes for any piece of technology sold for business). Read Salesforce’s Anshu Sharma’s pitch around VMforce if your enterprise-y cup needs a refill.

Misc. Comments

There’s a few other things to throw out there on the topic:

1. Azure – I look towards Microsoft Azure as one of the biggest PaaSes waiting to happen out there. In theory, there are a tremendous amount of line-of-business .Net applications (low priority, but needed for business to function, and usually more trouble to get rid of than to keep running) out there that, if the migration was easy, would be cheaper to run on Azure than on-premise. So far, I’m not sure if this theory is being pursed or is in the cards. Check out this presentation by Microsoft’s Prashant Ketkar at TechEd 2010 for some of that.
2. Retro-PaaS – People like Ning and ZoHo Creator arguably have PaaSes. Facebook apps can be seen kindasorta as a PaaS as well; Zynga might be the single, biggest PaaS user out there, technically.
3. ISV vs. Service vs. Corporate Use – as mentioned a bit above, when thinking about PaaS use, you need to divide up the type of business the PaaS user is in. Are they developing an application to sell (an ISV), a web/mobile/etc. service for folks to use (a SaaS or more traditional public web application, for consumer, business, or whatever use), or internal applications for use by their organization? Each of these types of developers will have different concerns and PaaS features they’ll want to take advantage of.
4. Apps vs. “crap-apps” – while the number of applications deployed on any given PaaS may be high, the conventional wisdom (an idea which I haven’t verified) is that the vast majority of those are “crap-apps”: applications that aren’t really used by many people, hobbyist apps, and other spaghetti thrown destined to be thrown at a wall instead of eaten.

What’s your take?

While these are observations and theories we’ve come across at RedMonk, I’m curious what your thinking is, dear readers. For those folks selling a PaaS, what makes that model attractive?
If you’ve been evaluating using a PaaS for your software, what have you been encountering? What excites you and worries you?

Disclosure: Microsoft, Salesforce, Intuit, MindQuilt, Joyent, CloudBees, and VMWare are clients, as are other relevant parties, no doubt.

The entries I looked over all were going for interesting ways to use the actual carrier networks (through services provided by Alcatel-Lucent kit and services, of course). My favorites involved auto-tracking of people through GPS and the networks – instead of having to manually “check-in” to various places, you could turn the services on to do that in the background.

The winner, which I thought was the top app, was called Late Runner:

Named “Late Runner,” Skrypachova’s application showcases the power of Alcatel-Lucent’s Application Enablement vision, which combines the trusted capabilities of service providers with the speed and innovation of the Web to enable a new generation of services and provide both consumers and business users with richer mobile experiences. Leveraging SMS and location APIs, the application enables end users to manage their day-to-day interactions with friends, family and co-workers by letting them track their physical whereabouts, informing them when they will be late to appointments, and providing an estimated arrival time. Built-in privacy controls allow end users to manage who they want to share their information with.

Read more about it and the runner-ups in the announcement released today and you can check out the details on their Top Coder page.

Disclosure: Alcatel-Lucent is a client.

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.

Tasktop and VMWare pre-announced an exciting service at SpringOne a short while ago, Code2Cloud: they’ve bundled up several parts of the software development tool-chain and hosted them in the cloud, as a service. Coupled with tight-integration in the IDE (via Mylyn and Tasktop), they have a nice looking package in the works (it won’t be available until 2011).

In this quick video, I ask Tasktop’s Mik Kersten and Neelan Choksi to give us a quick overview. Also, since they see the tools choices of many mainstream shops, I ask them what kind of git adoption they’re seeing.

In addition to watching above, you can download the video directly or subscribe to the RedMonkTV podcast feed to automatically download this and other RedMonk videos.

Disclosure: while both Tasktop and VMWare are clients, this video is not sponsored.

The relatively academic field of machine learning has found wide, consumer technology use in recent years: all of those “you like this book, you might like this other book” type of things you see. For most people (or, maybe, just myself) machine learning was always a tedious, math-heavy computer science topic. In this episode of make all, I talk with returning guest Grant Ingersoll about Apache Mahout which is seeking to bring machine learning to a wider audience:

Download the episode directly right here, subscribe to the feed in iTunes or other podcatcher to have episodes downloaded automatically, or just click play below to listen to it right here:

Show Notes

• Grant’s “Introducing Apache Mahout” over at developerWorks.
• A list of folks using Mahaout.
• The Apache Mahout page.
• Books galore! Mahout in Action, Taming Text.
• Grant’s stuff: Lucid Imagination, Grant’s Grunts blog, @gsingers.

Disclosure: the ASF is a client.

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.