Shared publicly  - 
 
Woah! +Scott Blum and I were just scrambling to shove bits out the door before midnight on July 4. The next thing I know, Scott's public G+ post[2] goes viral and now quite a few people are talking about #Collide .

I kinda wanted to work on it a little more before talking about it publicly since... well... its still missing features, general UI polish, and has bugs due to the rushed porting and open sourcing [1] :). But I guess since the cat is out of the proverbial bag, I should say a few words about it.

What did we open source?
You can probably infer from the source code what Collide used to be. I won't say more than is obvious from looking at the code. Namely, that it was a foray into building a hosted, browser based IDE. I won't speak about what we didn't open source (except that I think it was badass), but rather talk a little about what did make it out the door.

- Slick, collaborative source code editing (find/replace, quick open navigation, etc...) via a GWT based, highly performant, viewport rendered code editor that has affordances for inline nested rendered elements (Like Adobe's brackets with the inline nested editors) that can potentially be of variable height. +Jason Parekh .

- Client side auto-completions for HTML, CSS, JS and Python, with stubs to plug in more expensive server side "whole world" analysis later.

- JS debugging and live realtime CSS editing.

- Collaborative, realtime file tree manipulation (no "reload the file tree" nonsense. Add a file to disk, it pops into the tree on all collaborators in the workspace. Drag and drop move a file while collaboratively typing in the file, no problemo.)

This is a small slice of useful functionality that we hope can serve as a catalyst for realizing what our original intentions were with our project.

Why did we open source?
The Collide open sourcing is similar in spirit to the wave open sourcing in that it is a technology/library release, with a basic reference implementation provided out of the box. It is not a hosted service, or any kind of product competing with existing web IDEs like Exo or Cloud9. For example, we decided to make it first a local downloadable server, and skip on re-implementing user identity, and proper authentication, since those things are  relevant to a hosted product, and not to a technology demo.

We want the Collide opensourcing to serve as reference implementations for cool technologies, features, and interaction concepts we want to see exist in actual web-IDE services. These existing web-IDE services could leverage technology in the Collide stack. Longer term, some enterprising group could fork the Collide codebase and use it to bootstrap their own competing service. This can advance the status quo and be a win-win for users of these kinds of services.

But we've already seen realtime collaboration done before! How does this release advance the status quo?
We agree :)! Just realtime collaboration alone is not advancing the state of the art. But what was open sourced is actually the kernel of something much broader and game changing than just realtime text editing. There are some pretty gnarly ideas around code review and version control workflows floating around (not enabled) in some of the client code in Collide that we hope will see the light of day soon. There are some pretty crazy things you can do with a hosted development environment :). Also, the specific client implementations of the file tree and code editor we released are quite performant. Your development environment shouldn't be janky!

Over time, we hope to elaborate on this hand wavey proclamation with working prototypes delivered via the Collide client and server. As a start, we want to make client side JS debugging and live realtime-as-you-type CSS updating available via a Chrome extension that is already a part of the Collide release.

Anyways. I've rambled enough. Collide is now a hobby project for those of us who were affected by the Google Atlanta engineering relocation. The bigger project that Collide used to be was the product of some amazingly talented folks that I had the pleasure of working with at Google. You guys rock [3].

I am excited to get to hack on this as open source software, and to get to finally geek out in public about some of the things I have been working on :)!

[1] http://code.google.com/p/collide/issues/list
[2] https://plus.google.com/u/0/109697072684132989725/posts/WwRaBNhJAch
[3] http://code.google.com/p/collide/wiki/Credits
30
28
Ahmed Fathalla's profile photoJaime Yap's profile photoMorgaine Fowle's profile photo
3 comments
 
I have a couple of questions I just jtoted down(https://plus.google.com/113218107235105855584/posts/9uBBEqJ4JWr); my most burning is how you arrived at using #Vertx - it's such a new technology! How had you heard about it in the first place?

Second, how much of #Wave  is used and how much divergence, going off & doing your own was there? Is each file a Wave, are there Wavelets, how much remained? Was it chiefly the OT aspects that got used? Really interesting mix of technologies to make this slick product, would love to hear some more of the backstory.
 
Guys, did you put any thought into making this an Apache project under the Apache Incubator?
 
+morgain de la fey fowle  Sure!

I stumbled across vertx randomly when shopping around for a server container for Collide. The event bus and out-of-the-box SockJs support were nice. And the message passing isolation model mapped well to porting some of the existing server architecture.

I also happened to play with it and get a sample up and running quickly. Which for a Java based project says a lot :).

As for what parts of wave we are using. Not much actually. It doesn't really use any parts of Wave's collab stack. We implemented our own variant on OT that optimizes for viewport rendered editing of code (versus structured XML like wave did). So it is more performant for our use cases. You can open pretty massive documents and collaborate without any perf issues. We only really use the Keyboard signal event stuff from Wave since it is a pretty great library :). We still use a couple of modified Wave classes for managing the outstanding document operations (GenericOperationalChannel and the queue). But that's about it.

+Ahmed Fathalla We aren't opposed to it. But haven't put much though into it yet.
Add a comment...