As the founder of Codeanywhere a competitor in the Cloud IDE space this event saddens me. They worked for years trying to change the way people code, but did not make it in the end.
Contrary to what people may or may not think, they will be missed.
It would be easy to say that Nitrous' issues were due to technology or the market not being excited. But they went through 3 different CEOs and did not advance / innovate for a number of years after raising a bunch of money.
The market shifted on them and they didn't adapt to that. I think that in their case, they had other issues beyond technology that got in their way.
They were way way ahead of Codenvy and Che, and in many ways Cloud9IDE 4 years ago when all of us raised our money. And they just didn't adapt.
By all rights, my company, Codenvy should have been out of business because of Nitrous. They had a good 2 year advantage on us with Docker workspace management. They had top top tier investors with seemingly endless pockets and a native understanding of how to sell into the enterprise or with SaaS. Essentially, they had a stacked deck. If they had innovated or open sourced their IP it into the right community two years ago, we would have had no oxygen to pursue our Eclipse Che strategy.
That would have turned us into a #3 or even worse a #4 or #5 vendor. That would have cut off additional capital, not a great growth strategy, and death would have been likely.
At this point we are a #1 or #2 vendor, and likely the #1 vendor by revenues given the number of enterprises we have with onpremises systems.
I don't know what we would have done if Nitrous had moved differently 3 years ago, but for a number of years I obsessed about them as a competitor, refreshing their home page every day.
If it's ok to tack on here, how do you convince developers to move to Cloud IDEs? I've been trying to convince my team, but they are glued to PHPStorm and thus my attempts to move them meet steady resistance. The value-prop for me makes sense though, get out of the business of trying to maintain a vm on everyone's machine. Granted maybe we could solve it in other ways with containers or such but Cloud9, Codeanywhere, and some of these other tools seem like the right thing to move to.
I'm going to get flack for this, certainly in this discussion, but... seriously? What is this obsession with cloud IDEs?
The reason you can't convince me is that nobody has ever been able to explain in clear terms the benefit or the point of using a cloud IDE.
A cloud IDE presupposes excellent uninterrupted connectivity. Guess what? I often work on the move and often don't have that.
I'll admit that keeping Visual Studio service packed can be tiresome but this irritation is vastly outweighed by the fact that I can use it on the move. Likewise Sublime Text, or WebStorm, or whatever. And it's not as if software updates can't be solved in a different way (Chrome, Firefox).
For me the combination of a locally installed IDE with a distributed version control system still offers the best value prop for working portably.
I'm not saying a cloud IDE is always a terrible idea but, after 4+ years of these things, I still don't really get the appeal.
As a former volunteer CS instructor (for high school students), the cloud IDEs were great for use on school owned hardware that got wiped randomly, often had boot issues, etc.
As long as the students had a working machine, they'd be able to get to their projects regardless of whether it was on the machine they used the previous day (without have to deal with git/etc).
In my professional life I would never use these tools.
I use them the same way. I find git as a single developer to be also a much better fit for me. I work in three different locations on three different machines and a laptop. Git works for me, but I have taught some and the cloud IDE is great for teaching.
To be honest I think we need to stop thinking that "cloud development" needs to be in a browser. People like to do all sorts of things with their IDE that I certainly hope browsers never let pages do, like intercepting certain command keys, controlling the layout of multiple windows interacting with and knowing more about the user's display dimensions and multi-monitor, etc.
Not to mention things like vertical-selection, or multiple cursor modes for column editing, which can't be done at all in any of the current web-based editors which AFAIK are all based on contentEditable rather than a custom renderer like the original Bespin (I think, that thing changed codewords a lot).
Now some of these can be addressed with Electron or similar, but there's a lot of things that are nice to do in a code editor that just aren't compatible with the DOM itself, and need a deeper customisation of the rendering and input management.
Well, I can't speak for the ones here, but the three times I tried to demo c9 to my team (at the time) c9 was down, partially up and/or really buggy. Given this was a few years ago now, but that really soured me on the idea.
This was a dream for coding bootcamps, classrooms, etc. Unfortunately I keep hearing from lots of places that you just can't make money in edu. But man, I love these tools for teaching people how to code. It's the only way to go.
I really disagree with that. If you're learning how to use it then you should also learn how to install it, and use it outside of the learning environment.
And by the time that you've installed it once, it won't be an issue again.
No. If you are going to develop professionally with a language then you should know how to install the environment. But that's a huge ask for people just learning.
I have fought through issues of setting up a development environment for modern web development for the last ten years in boot camps and classrooms. When everyone brings their own device, you run into tons of issues you can't control. Students get confused by differences in terminals, text editors, and many other factors. The instructor's environment must match what the students have. And these allow for that.
And if you think "well, if they can't bother to set up their own evironment, they shouldn't be writing code cos they're not smart enough," I'll offer this. While I agree that it's important to know your tools as a professional, we are not talking about professionals here. We are often not even talking about people who want to be professional software developers. There are many people who have studied their field for years and are probably much smarter than many of us here are now getting into code because it's a tool for them to do their work better. It is in my opinion arrogant to insist they set up their own tools before they can learn what we do.
I'm not saying we shouldn't teach people who aren't "smart enough". I'm not saying that there should be a rite of passage of "learn Emacs/VIM, learn bash, learn to hate bash, learn zsh/fish, ..." that everyone MUST go through in order to be considered worthy of learning anything. Nor should messing around with $PATH be a requirement to get started.
But I think that the tools used in the education should neatly transition into tools that they can use for personal stuff, both during their education, and after they finish it. And it definitely shouldn't be using any "Educational" editions that time-bomb as soon as you leave school.
Sadly, I'm not sure of anything that offers this in a turnkey package today. To me, the closest seems to be IntelliJ IDEA (community edition, of course) which apparently ships an embedded JDK these days, and the instructor can ship a Maven/Gradle project definition that handles the rest of the environment that should be available.
Depends. I spent some time teaching high school students. A large portion of them will not write any code after taking the class.
Teaching them how to install and configure an IDE is a pretty useless skill in that context.
Instead, even if they never code again, teaching them a little bit about how to think like a computer and some basic computer skills (many of them were almost computer illiterate) seemed like a much more valuable use of time.
The big ones left seem to be Koding and Codenvy. Codenvy focuses on Eclipse Che. Koding is focussing more on Dev infrastructure than the online IDE. Even Heroku started as an online IDE.
I wonder why online IDEs have such a hard time. I asked in GitLab and everyone said they didn't want to code in a browser for usability reasons. We're therefore exploring running the environment in the cloud but syncing the file system so you can use you local editor https://gitlab.com/gitlab-org/gitlab-ce/issues/22876
What do people think? Is this the way to crack to problem and break the online IDE spell?
1. A web IDE is widely used at Google and has instant syncing with the file system so you can use your local editor and immediately see the changes in the IDE. This is probably helped by the fact that your "local" code is actually a distributed filesystem mounted via FUSE.
2. Features of the web IDE that people love: it works offline via caching and syncs back up the same way you expect an offline Google Doc you were editing to sync. It has plugins (e.g vim bindings) that are most common feature requests from developers. You can build your code very quickly (yay distributed building). No startup time, it loads close to instantly like Google Docs does. Split pane editing, debuggers, linters, etc all built-in. Code search also built in, review tool integration, version control integration.
3. Outside of Google people don't want to pay a 3rd party to allow editing / storage / access of their code; it mostly comes down to "if I get used to a tool I need to be guaranteed it will be around forever," (open source solves this), "I want full control of where my code lives" (on-premise solves this), "performance + features" (not sure if this has been solved anywhere, like being able to modify your code locally and remotely and sync instantly)
1. So the web idea syncs with the distributed filesystem before any commits are made. We plan to sync the filesystem of the application development container to both your local filesystem and to another container that runs the web idea. That would allow for the same effect, or not?
2. Pretty cool it has operational transformations (OT). We looked at this but it seemed that you either have to pick someone with OT or something that works well with code. We're not doing distributed building but we're considering distributed testing https://gitlab.com/gitlab-org/gitlab-ce/issues/19267
3. Yeah, this would work on your local GitLab instance, no third party needed.
1. Yeah, but it needs to handle unstable web connections gracefully. There's no locking in the UI even when your connection goes down, and when it comes back up it just uses last edited version (whether you made changes on your desktop or in the browser). Definitely tied to #2, which is that you need a sane way to merge conflicting changes.
2. I don't know for a fact they're using OTs but given that you can edit from local / web pretty much simultaneously that's a good guess. Since you don't generally get actual simultaneous edits however (or you don't really have to optimize for this use case since a dev is either editing from the IDE or locally and "simultaneous usage" would generally be a product of network latency), one idea is you could use a tree-like CRDT that tracks divergences and have a UI element that allows nice manual conflict merges. Or you could invent an automated merging strategy, which may or may not be pretty hard.
2b. in re distributed building, https://www.bazel.io Google actually open sourced their build system but I'm not sure (I don't think) the distributed building aspect of it is included. Here's to hoping some headstrong engineer decides to write the open source version of it...that said it's probably not actually that important for most software
3. Cool. I'd love to see something like this from Gitlab! I think once people feel that they have control over the software and their code, it's all about usability, and if you nail that there will be plenty evangelizing the solution.
> "if I get used to a tool I need to be guaranteed it will be around forever," (open source solves this)
It solves it partially, but it creates a new problem: if the supporting OSS team that does most of the maintenance of the IDE goes away, you've traded one problem for another. If you want to keep using it forever, you'll need to keep maintaining it forever.
Google was working on a web IDE called Brightly back in 2012. But instead of releasing it as a commercial project, the company released the open source Collide project instead. I'm not sure how much of Brightly went into the web IDE now used internally.
I guess I'd turn the question around and ask what problems are browser based IDEs trying to solve and what advantage do they have over regular IDEs?
I'm a full-time C++ developer, which probably isn't the target for most browser IDEs, but I'll throw in my two cents anyway.
My perception is that browser based IDEs are inflexible, fragile, slow, and don't scale. It's not even clear to me how a browser based IDE is supposed to work in my environment. Do I clone our source repo locally and open the file from there somehow? Do I clone it to the cloud somewhere? How does a browser IDE handle the third party libraries we link to? Where is compilation done? Where does the executable go? Am I able to debug and step through the binary in the browser? What if there's a GUI component?
And don't even get me started on the clunkiness of text editing in a browser compared to an editor like Emacs or Vim.
The whole concept of a browser based IDE just seems like a poorly thought out abuse of web technology.
Good points, running the environment in the cloud and the editor locally helps with some of the points, but doing debugging is hard. As a ex ruby developer I'm used to having an editor without the other IDE functions. I guess that IDE in the cloud is a big step from editor in the cloud.
I personally think it is due to a lack of true innovation, most cloud IDEs are just copies of native IDEs minus the performance benefit. The browser is a powerful platform and when you combine that with a server you have something very capable, but you have to think creatively to harness that power.
I think you have to ask why a developer would want to use an online IDE, and focus on that. Do online IDEs have a unique value proposition, or are they just another instance of the counterproductive "X but in the cloud!" formula?
I have the feeling that people want to build online IDE's and that management thinks it is a good idea. I've not encountered many developers that like to use it fulltime. One counter example is https://community.nitrous.io/posts/nitrous-io-stories-yehuda...
>I asked in GitLab and everyone said they didn't want to code in a browser for usability reasons.
Can't speak for anyone else but I'm constantly battling to keep my browser from crashing due to too many tabs. Namely Chrome and Firefox on Linux and OSX. I open tabs, then forget to close them. Even as I write this Chrome is popping up alert boxes saying so-and-so page has stopped responding, do I want to Kill or Wait? The thought of adding a fairly heavy-weight SPA IDE to that mix is not attractive.
Out of curiosity, can Atom (https://atom.io/) load a remote IDE into its separate memory space? Only best-of-both worlds I can think of.
Eclipse Che is doing pretty well. Approaching 20,000 usage hours every day from telemetry, up from a couple hundred at the beginning of the year.
Eclipse Che is focused on the dev infrastructure. It's about making the workspace completely portable and provisioned on any system without any effort from developers to have to set it up.
Lots of use cases:
1. Hosted workspaces with workspace project sync - we provide a che-mount capability for this and it's based upon a fuse file system with unison sync. It can be fine-tuned with excludes and dual unison clients in such a way where the performance is really screaming.
2. Migration of workspaces from location to location for purposes of backup and recovery.
3. Having workspaces match their production topology, so that developers are working on a workspace that is identical to their production deployment. This requires workspace runtimes that are constructed by orchestrators like compose or other syntax.
4. The commonly discussed situations with instructors or team leaders setting up a workspace template which is used by others to facilitate getting started quicker. We are about to launch a team capability that allows a team leader to define a basic template of a workspace that is defined by stacks, composefile structures, and other meta data, but more importantly it explicitly states the aspects that are personal to each developer, so as each developer creates their own workspace replica from the template, they have to populate it with their personal information such as SSH keys, oauth access, database credentials and so forth.
5. Big software vendors value the extensibility of the che platform because there are many products that need workspaces inside of their products, and they would rather customize an off the shelf product vs. build their own.
6. Better agile. Context-sensitive pull requests, git issues, git repositories, issues, and CI jobs - opening a context-aware workspace is a big deal. We do a lot of enterprise customers that focus on those cases. It's hard to set this up on a desktop or with vagrant.
We try to stay out of the IDE conflict. We are happy to work with any desktop IDE or provide our own for those that don't want to install something. But we are close to a future where each workspace can host multiple IDEs at the same time, including desktop IDEs that are pre-configured to work with the workspace configuration.
The point is that if you sit 5 developers around the table and ask them if they want to code in the browser, you can anticipate the response that you will get.
But if you sit 5 development teams around the table and ask them about problems they have with developer onboarding, agile team management, collaboration, developer support, vagrant and using VMs / virtual labs as development environments, then suddenly there are a lot of pains around the table.
We think Che is doing really well because we have tapped into this particular need with some efficiency. And we consciously try to avoid being the world's best IDE because of the issues stated previously.
Also, with the language server protocol that we announced with Microsoft and Red Hat this summer, it has really taken off. I can see us having support for 20 languages with intellisense + debugging by the end of Q1. It allows the language providers to maintain really good intellisense and we provide the infrastructure around that. And then we can focus on workspace provisioning and giving developers access (without installing software) to intellisense for the languages they love. And 90% of the world is covered by the 75% capabilities of most language servers on the market. So we can be increasingly language and tooling agnostic, while providing great services to teams.
Along these lines, we have a new team management offering shipping in a few weeks, not to mention Che 5 - which we'll announce at CheConf. And CheConf is our first users conference that we are holding on 11/15, and after two weeks of promotion, we are pretty stunned that we are approaching 1500 registrations.
Nice no-nonsense shutdown post. I kinda miss the nonsense though.
Like why are they shutting down, are they keeping their static-hosting service Pubstorm, and if so, how - at $5 per month - can that be more economical?
A couple years ago when I was first learning to code all I could afford was a cheap chromebook and nitrous enabled me to learn and grow as an engineer with very little barrier of entry.
I am sad they're shutting down, but more for sentimental reasons, I haven't used nitrous in over a year and once they dropped their freemium version I couldn't convince myself to come up with the cash to use them.
What was the value proposition of this (and other services that are still alive)?
We can already use git to store code in the cloud AND do so only when we want to. Was it the containerized environment? Even in that case why wouldn't they provide some sort of "dropbox for coding" type of service instead?
I tried Nitrous a few times and thought it was nice, but I kind of feel like it's the wrong decade to start depending on a proprietary dev tool you can't host. Being able to install Cloud9 on your own computer was great if you were xx - xxx ms from a server or offline.
Hopefully their software resurfaces with new opportunities when it's open sourced.
As the founder of Codeanywhere a competitor in the Cloud IDE space this event saddens me. They worked for years trying to change the way people code, but did not make it in the end.
Contrary to what people may or may not think, they will be missed.
What's left? c9.io what recently bought by Amazon. There's codenvy still, which is migrating from codenvy.com to codenvy.io for some reason: "The legacy IDE at codenvy.com will be shut down on Friday, November 4th 2016. This is the last phase of our 3 phase sunset for the legacy codenvy.com system (details are below this message). Your account will be automatically migrated to codenvy.io. You will need to reset your password upon first login in that system."
Codenvy's C3 legacy system is shutting down and merging into codenvy.io, which is a next-generation platform based upon Eclipse Che. We have been running both systems in parallel for about a year now, and this weekend we will merge them together.
No matter how hard we tried, we were still getting about 1000 signups for the legacy system / week. The new system gets a lot more, but we just couldn't find a good way to merge the two systems earlier. It would have been nice if the usage of the legacy one had fallen off, but I actually think it kept increasing. So instead of having a really clean transition point, we ended up with three systems:
1. Eclipse Che open source going bonkers.
2. The classic codenvy.com which was growing in usage
3. The new codenvy.io, which was growing as fast as Che.
From a consumer perspective, what's wrong with c9.io being purchased by Amazon? Shouldn't that mean more stability and an acceptance by enterprise of cloud coding?
If you're in the EDU space, give repl.it a try. I've met the founders (@amasad & @HayaOdeh on twitter) and they're super passionate about what they're doing.
How about Koding? I always thought of Koding to have a similar proposition.
I was looking at their site today and they claim 1,000,000 users on their website. How many developers are in the world? 11 million or so? So about 9% of world developers use Koding and somehow I have missed pretty much all of them.
I've read many comments on this thread regarding usability and value-prop of online IDEs. Here are some points from a perspective of a developer who was relying heavily on Nitrous.
1. I was able to patch my production apps from anywhere.
2. I was able to deploy my apps, in-case my hosting service provider decided to reboot the servers while I was at home, away from my development machines.
3. I was able to build new features, on alternate git branches, while enjoying at home with my family.
4. I was able to host new features, from a development branch, and let my colleagues provide real-time feedback.
I am one of the developers who will be crippled if online IDEs like Nitrous go away.
I do that all now with a mixture of rdesktop/rdp and SSH and occasionally Emacs tramp mode over a VPN.
Basically if I have my local emacs I can use it even when the dev, test and prod servers are 1000 miles away, and if I don't have my emacs (on my tablet or something) then its rdesktop/rdp and run my IDE remotely.
My current employer is pretty chill with all my machines being 1000 miles away in a corporate national data center, but is not chill with the idea that some 3rd party will host the critical development path and connectivity could disappear at their whim.
Its the classic "cost too low" problem for PaaS. My code, no matter how important it is to me or my employer, cannot be worth more than $39/mo to Nitrous in some kind of worst case scenario. Actually its only worth their cost of sales to replace me, which might be higher or lower, but certainly isn't a lot of money. On the other hand my management team can escalate a locally hosted problem such that a big enough problem might in theory cost multiple sysadmins their job, maybe their boss too, lets say a max of $500K/yr if multiple people got fired for over the top gross misconduct. That means my boss has AT LEAST a thousand times more leverage in case of problems with self hosted vs PaaS. There's a big difference between "eh $40 here, $40 there, who cares about that trouble ticket" and "our shared veep said you'd fix ticket #24153 before going home today or you're unemployed". "I don't care if your total budget is $10M/yr or a thousand people are sitting down waiting until its fixed, you're only worth $40/mo to me and not a penny more, tough luck".
I mean, seriously, 14 days warning? I've taken longer than two week vacations. Imagine coming back from a long vacation and trying to log in to get some work done and finding out everything was wiped a week ago, LOL.
I have been a daily user of nitrous since February 2014, the news hurts like a punch in the stomach,
thanks to them I started programming again after a 15 year break. It feels as if a dear friend and office mate was diagnosed with 15 days of life. Such a bummer, Hope the best for the team.
I recommended Nitrous in my book 'Learn Ruby on Rails.' The service is ideal for beginners who have difficulty installing Rails on their local machines. It's a useful service but I presume they don't make money with the beginner/educational market. It didn't help that they dropped their free tier snd then brought it back months later. Sorry to see them go.
I coded in the cloud full-time for over two years and loved it. I switched back and forth between Cloud9 and Nitrous based on plan changes and new features. The primary reason I switched back to local was for better Cordova debugging and Electron. For web development, it was really nice.
I'm exploring Electron already, so out of curiousity, what did you build with Electron? Any recommendations of a good "starter" app/tutorial/walkthrough?
I've been happily using the nitrous.io service for 2 months to play around with Meteor. It is a great service. I quickly defaulted to the shell with tmux rather than using the IDE. Hosting was only $19/month which hit the sweet spot between shared hosting and a VPS.
Shared hosting for Meteor is not an option as a 'meteor update' always runs out of memory and gets killed for using too many resources. You can upload a config, but this is unwieldy and is antithetical to the whole point of Meteor.
Let me start by stating I am the release manager for Codenvy and Che. When trying to decide if a cloud IDE is right for you like so many things in life "It depends". A local IDE probably works "fine" for most single developers or small teams. Developers that have been using a certain local IDE may find that it is better to stick with it than to invest time in learning about and how to use a cloud IDE. Also certain program development can only be done with specific local IDE software. Codenvy is trying to fit into as many developer needs as we can but we know we will not always be right for everyone.
However, Codenvy and Che does have advantages over local IDEs. The biggest in my opinion is having a consistent programming environment that can be distributed quickly. We leverage the use of Docker in creating workspaces that run machine(s) which are Docker containers. Source code, compilers, debuggers and executables are all "contained" in the same runtime environment. This means consistency in compiling, executing and debugging. When a developer get's something to work successfully others will be able to do the same consistently. Also, transitioning from development environment to production in most cases is more consistent and faster if your production environment uses or can use Docker containers in production. Running the IDE on a dedicated server also can increase compile performance and reduce local machine hardware requirements.
One special advantage that Che and Codenvy over traditional IDE's is some embedded systems. A developer could include a built-in IDE in their embedded system. When the embedded system is connected to a network the developer could use Codenvy or Che to directly reprogram the device using the device's ipaddress and a web browser. Downside to having the IDE on the embedded system though is processing power but could work in some cases. Alternatively, a cross compile development environment could be setup with Che and Codenvy that could upload the binary/assembly to the embedded device after compiling. This is actually what we are doing Samsung's Artik development board with the Artik IDE.
On the topic of leaving a developer "high and dry" if the product fails, is why open source is a good idea for an IDE. Open sourcing Che, which Codenvy is built on, ensures that the product has the ability to live on without us if for some reason Codenvy fails. Not only is Che open sourced but is part of the Eclipse foundation.
This is a great topic and glad to see all the interest. It's good to see what developers feel about and want from cloud IDE's.
Sorry to hear this. I always thought Nitrous had a pretty nice platform compared to other cloud IDEs and Peter is a great guy that was building some cool stuff. Wishing the folks at Nitrous all the best in whatever comes next.
Well, this is sad. I miss the old Nitrous.io. The new updates they rolled out suck, and now that they are completely shutting down the service I'm just even more disappointed. Back to PythonAnywhere I suppose?
PythonAnywhere dev here -- we'd be very happy to have you back! (Especially if you tell us what made Nitrous a better platform while they were still operating.)
We trialed Nitrous with our kids at ScriptEd (after school coding non-profit) a couple years ago. Their free tier was leaps and bounds above Cloud9. Sad to see them go.
I'll admit I haven't seen the editor since summer '14, but it was honestly shit then.
The only thing I saw it used for was abstracting away environment setup for kids at a high school coding bootcamp, which I can forgive because it was only like 10 days. I'd be suspicious of anyone using something similar professionally. 1 day of environment setup is nothing in the context of a professional project.
Contrary to what people may or may not think, they will be missed.