Tyler Jewell, CEO of Codenvy, recently received 9 million new reasons to believe in the browser-based Java IDE. Codenvy began as a side project for enterprise social Web framework eXo Platform, but in early March, Codenvy launched a beta for developers to try out around the world.

Jewell is no stranger to enterprise Java development. His resume includes vice presidencies at Oracle and Quest, and a directorship at BEA Systems. We caught up with him shortly after Codenvy raised its initial US$9 million investment from venture capital firms Toba Capital and Auriga Partners, which clearly also believe in the power of a browser-based IDE.

Jewell preaches Codenvy as a cure for the woes of IDE standardization. Typically, developers installing an IDE must configure their IDE to their liking; add in all the libraries and tools used in the enterprise; and link into the build, test and deploy systems. That takes time, and Jewell sees a Web-based, easily replicable cloud-backed alternative as the solution.

SD Times: What is the grand goal for Codenvy, say, five years from now?
Jewell: We believe that in five years, there is no reason any new development should take place on the desktop. If you think about it, every application that runs and operates on the desktop has already moved to the cloud, with the exception of the developer workbench. The reason Tyler Jewellis, oftentimes, developers are incredibly particular, and they’ve felt like they needed a specialized environment. But we’re starting to realize that the problems that arise from developers working on the desktop are starting to mount up, and we can eliminate all those problems with a cloud-based development environment.

Codenvy is taking the logical next step by taking the developer workspace and moving it into the cloud, making it scalable, sharable and clone-able. The net effect is that most developers can be more productive, in a number of ways, by developing in the cloud than they could have been on their desktop. We’re already starting to see the transition; our growth is starting to kick in. We just crossed 50,000 users.

It feels like your benefits are similar to GitHub: sharing, cloning and forking in a public way.
The parallels are the same. With GitHub, their focus is around the repository life cycle of that. In our world, the workspace itself is a combination of the editor, the build process (which is a runtime), and a test process (which is also a runtime with access to the files that make up the project). Those files have been checked out into a construction phase. When we say cloning, we’re cloning all those elements, the editor, its configuration and the state of those files.

When I talk to you about clone-able components, we call that a factory URL. You can take a “Hello World” example and create a factory around that. We create a sandbox for someone, check out the “Hello World” application, compile it, validate that it has no errors, auto-create the account on Google App Engine, deploy the WAR file, and launch the debugger. The developer gets that in 30 seconds. That would take four to six hours today.

We can completely remove IDE issues from the planet. When I think of all the APIs ISVs are trying to on-board developers with, I think they’re doing it in the most painful way possible.
What does the work look like to and from Codenvy?
We provide Maven build capabilities. In the Maven build capabilities, you can refer to Maven Central, things can be downloaded locally, or you can upload your own.

The version control is deferred off to your Git provider or your version provider. If you’re using Maven Central, they have versioning and team-based controls. You can do integration into any artifact repository, or Nexus server, or a private JFrog server as well.

What languages are supported in Codenvy?
Our emphasis is on the enterprise, particularly teams with five to 20 people on them. As a result, a lot of what we’ve done is for those things that are compiled languages: Java, Objective-C, C and C++. We don’t have full support for all of those, but we are building the workflow around those.

We have language support for a wide range of interpreted languages. Fifty percent of our user base uses interpreted languages like PHP and Python.

What’s next?
We get about 20% of our traffic from developers who are using mobile devices of some sort. We don’t have mobile support yet, but I was blown away by guys saying, “I am on my iPhone.” That’s a huge amount of traffic.

As a feature request, we’ve had 80 votes to formalize tablet and touch support. I think, “Why would someone want to build on their tablet?” But there are situations where people are on the couch, and they want to run to the desk, or they’re on vacation and have to change something.