"Open Source Programmer's Text Editor" project on Kickstarter - can we help?

[Jon Spriggs]

I spotted this project [1] today, and I'm backing it. I wonder, as
Michael already has an Unhosted text editor, can we contribute by
getting this to be an Unhosted-optional service once the project is up
and running? They already mention it'll be able to integrate with
GitHub, S3 etc

[1] http://www.kickstarter.com/projects/1241383920/open-source-programmers-text-editor-using-canvas-a

All the best,
--
Jon "The Nice Guy" Spriggs

[Leen Besselink]

I wonder if the author and you know about Ace:

https://github.com/ajaxorg/ace
http://ace.ajax.org/

Which is used in:

http://www.cloud9ide.com/

And partly came out of the Mozilla Bespin/Skywriter project:

http://mozillalabs.com/skywriter/2011/01/18/mozilla-skywriter-has-been-merged-into-ace/

Which showed using just plain DOM-elements and not the Canvas-element
had a lot better performance for them.

Anyway, it would have been good to show why the author of the
kickstarter project choose what he/she want to do and shows what others
are doing and why this project is different/needed.

[Michiel de Jong]

looks awesome! I also had the first reaction 'why not use ace or codemirror?' but maybe he can do cool stuff with WebGL that these others don't.

yes, he mentions github and dropbox, and how these can be integrated because basically all such services offer a http interface for storing and retrieving, that integrates with javascript. That's exactly what we are promoting with our project.

So there are two answers:

In the weak sense, this is already an application that (if i understand correctly) allows unhosted storage. it would use your github account or your dropbox as the data storage, and not provide same-origin storage.

In the strong sense, in the long run we could ask him whether apart from the github and dropbox APIs, he can add a third API, which would be oauthed, cross-origin webdav (as is our current standard). to be realistic, i think we should let him develop the app the way he planned first, it's already awesome enough the way it is. The same goes for OpenPhoto, who also mentioned dropbox and s3 as per-user storage backends. Then once it's finished, we can think how we can convince such projects to use a more open protocol than github, dropbox and s3.

I'm saying this because i'm not convinced that our current version 0.1 is the final answer. maybe even, we want to reach out in the other direction, and include compatibility with proprietary APIs. I have mentioned that idea several times in various context, and nobody, not one person, has ever agreed with me on that. :) Everybody says we should require people to migrate to open standards, and not water things down by adding support for currently popular, but proprietary API standards. So I don't know.

But one thing is definitely awesome: that people are starting to write web apps that allow some sort of 'unhosted' storage, in the sense that they provide web apps, but not data storage as part of their product. What protocol they use to achieve that is to me a matter of mere implementation. Maybe people disagree on that?

Cheers!

Michiel

[Leen Besselink]

On 08/01/2011 10:56 AM, Michiel de Jong wrote:
> But one thing is definitely awesome: that people are starting to write
> web apps that allow some sort of 'unhosted' storage, in the sense that
> they provide web apps, but not data storage as part of their product.
> What protocol they use to achieve that is to me a matter of mere
> implementation. Maybe people disagree on that?

If people 'get it', that really is awesome.

The protocol is to facilitait interoperability, that is why it is good
to have an open specification.

And it really helps to have a recognisable name or even button so people
who know what it means know immediately when something is supported.

Yes, everything else is an implementation detail.

[Leen Besselink]

Maybe I should add, if there is a reverence implementation this really
helps with the adoption of a protocol as well.

But I'm not sure why I'm explaining this to Michiel, I think he knows
all this. :-)

Maybe I misunderstood the question.

[Michiel de Jong]

Hi Leen!

I agree with some of your arguments. If we were to design an ideal world from scratch, we would make sure we use only one protocol from the start, to make interoperability as easy as possible. However, I think we shouldn't overestimate this need either. Because implementation details can be abstracted quite easily on the client-side. It's very similar to the situation with the DOM. Yes, in an ideal world, all DOM implementations of different browsers would be interoperable. But in practice, that hasn't happened. Instead, people started using jQuery, GWT, YQL, etc. to create the layer that DOM should have been, on top of what DOM is. It's super ugly. But it's not a show stopper we can't work around.

I am already of the opinion that we should move to the least common denominator of webdav, couchdb and camlistore. Adding proprietary APIs like dropbox, s3, github (and while we're at it, GoogleDocs jsapi) to these three open standards doesn't move us a lot further away from the goal of a unified standard. If we already needed a client-side abstraction layer, then we might as well add support for a few more APIs to it, as well.

The recognisable name and reference implementation (i agree with you these are important), are not absent from the proprietary APIs. In fact, those names are a lot more recognised and their api implementation is a lot more mature than us right now.

I think the real discussion point is whether we should support 'only open APIs' or 'open as well as proprietary APIs'.

Mind you, it's not even accurate probably to call these APIs proprietary. I would have to read the license, but i doubt that Amazon forbids to create "S3-compatible" storage, that mimicks the API they introduced and branded?

Also, I don't know which API github exposes, but I assume it's git, or git-over-http or something. So there, you could even say 'connect to your git account, for example your github or gitorious or codetu.be account'.

I think the argument pro including proprietary APIs is that these have the installed user base, and even though we do not free the users that are on these proprietary data servers, we do gain chicken-egg momentum with it, and offer users the /choice/ to be free as soon as they're ready for it.

I think the argument against including proprietary APIs is that it makes it too easy for people to keep using them, and once you allow them, you might never get rid of them. And it would even strengthen the position of non-free services like dropbox. if we don't promote owncloud, couchdb, camlistore and locker project over dropbox every chance we have, then we are helping dropbox further their monopoly.

a third option would be to support the APIs of proprietary services for a limited amount of time, or with a warning message. That way, we lure people in first by supporting the data server where they're already on, and then once we're in, we keep displaying warnings. there, we could use something like Azaaza's privicons to convey to the user how bad the services that they use really are. and with time, as our foothold grows, we could even increase the warning levels. like on ubuntu: you can install nVidia drivers, but only if you click 'yes, i understand that this is bad' several times. i think that is a more effective strategy to affect consumer behaviour - it allows you to have a bigger user base, and thus for your gospel to reach a bigger audience.

Maybe I can get some support for this third option from anyone? As I said, it's really striking how to me it's obvious that we should include support for APIs of all services, including the bad ones, yet nobody else, ever, not a single person, has even only remotely agreed on that with me. :D Maybe that's a sign that I'm wrong about this? ;)

[Leen Besselink]

Hi Michiel,

If you put it like that, then it is clear to me I misunderstood the
question. That is why I also popped into IRC to see if you were there,
but you were not.

I have no problem with having a reference implementation which also is
able to connect to other (open or not) services to speed up adoption.

You can also approach it from the other side, it might actually help to
see what kind of things we don't yet support, thus get an idea about how
others have solved things.

> Mind you, it's not even accurate probably to call these APIs
> proprietary. I would have to read the license, but i doubt that Amazon
> forbids to create "S3-compatible" storage, that mimicks the API they
> introduced and branded?
>
> Also, I don't know which API github exposes, but I assume it's git, or
> git-over-http or something. So there, you could even say 'connect to
> your git account, for example your github or gitorious or codetu.be

> <http://codetu.be> account'.
>

Well, there is an implementation of Git in JavaScript ;-)

https://github.com/danlucraft/git.js

> I think the argument pro including proprietary APIs is that these have
> the installed user base, and even though we do not free the users that
> are on these proprietary data servers, we do gain chicken-egg momentum
> with it, and offer users the /choice/ to be free as soon as they're
> ready for it.
>
> I think the argument against including proprietary APIs is that it
> makes it too easy for people to keep using them, and once you allow
> them, you might never get rid of them. And it would even strengthen
> the position of non-free services like dropbox. if we don't promote
> owncloud, couchdb, camlistore and locker project over dropbox every
> chance we have, then we are helping dropbox further their monopoly.
>
> a third option would be to support the APIs of proprietary services
> for a limited amount of time, or with a warning message. That way, we
> lure people in first by supporting the data server where they're
> already on, and then once we're in, we keep displaying warnings.
> there, we could use something like Azaaza's privicons to convey to the
> user how bad the services that they use really are. and with time, as
> our foothold grows, we could even increase the warning levels. like on
> ubuntu: you can install nVidia drivers, but only if you click 'yes, i
> understand that this is bad' several times. i think that is a more
> effective strategy to affect consumer behaviour - it allows you to
> have a bigger user base, and thus for your gospel to reach a bigger
> audience.
>

Yes, a warning or maybe removing an Unhosted logo or something like that
is an option.

While you are mentioning Ubuntu and you are making lists I think Ubuntu
One also has an storage-API.

> Maybe I can get some support for this third option from anyone? As I
> said, it's really striking how to me it's obvious that we should
> include support for APIs of all services, including the bad ones, yet
> nobody else, ever, not a single person, has even only remotely agreed
> on that with me. :D Maybe that's a sign that I'm wrong about this? ;)
>

I have no problem with that, I just have a 'warning'. You'll have to
keep an eye on the project and not loose focus on what it is trying to do.

[Michiel de Jong]

On Mon, Aug 1, 2011 at 9:01 PM, Leen Besselink <le...@consolejunkie.net> wrote:

I have no problem with that, I just have a 'warning'. You'll have to

keep an eye on the project and not loose focus on what it is trying to do.

That sounds like good advice! I'll try. I know of myself that I have very chaotic focus, so i often take a moment to reorganize priorities.

I am thinking towards a wrap-up of all the current loose ends, putting it all together and documenting the parts that we have working. In 6 weeks is our project's first birthday, I was thinking of using that date as a version tag, to find out where we stand. What do you think?

One thing I hadn't expected is that there would be so many relevant things to research. I thought that when we had version 0.1 of the standard, we would just start writing apps. But I think the current focus is OK. People are writing useful apps, while at the same time we're still researching all the options very actively.

I agree with you that we should probably not spend too much time right now implementing the details of specific proprietary APIs. I was thinking that we can do that in version 0.3. But other than that, what do you think should currently be the focus?

Cheers!

Michiel