His point was that the software might be free but there was too high a cost struggling with difficult installs and ugly user interfaces. You can stand out if you bridge that gap.

Did you catch what Matt Mullenweeg said yesterday at Startup School why WordPress succeeded in the early days? He said it was because WP had the quickest and easiest install of any blog software.

Bringing tech we use every day to a wider audience is a viable business model.

Well, that's where the common misunderstanding is: free software is not about the cost. When you factor in the cost of having access to the code and of having the rights to redistribute the programs and of being able to make derivative works, the equation, IMHO, is usually in favour of free software.

Remember: free as in freedom, not as in beer.

Having said that, I agree with what you are saying - I often use proprietary software because it fits my needs better or is in some other way superior and I don't require the source code or freedom which the free software alternatives would give me. If I did, however, then the free software would, indeed, be cheaper, even factoring in the hidden costs.

My main goal right now, aside from building a Node.js hosting service, is to create a platform for content and data management built on Node.JS, CoffeeScript, and NPM, with a plugin and component architecture. I dream about killing WordPress.

For example, I hate most of the Microsoft Office suite, but there really isn't anything that's better for the average user to author documents. I dream of making something that's so good that people will switch and I won't have to deal with Office ever again.

And just because I didn't get into detail in regards to the advantages doesn't mean that wasn't the an important part of the motivation.

For a platform like this, there are two sets of users: the non-technical users and the software developers building plugins and components for the system (not buzzwords).

Let me explain exactly what each of these words means technically in this context so that they cannot be mistaken for buzzwords. I will admit that 'plugins' and 'components' can often mean different things to different people, but I don't believe there are better words to describe what I am building.

Plugins are extensions to the system which are easily added, integrated and configured. This is a feature which is missing from a number of sophisticated web frameworks, but not missing from WordPress. The biggest problem with WordPress is the language it is built on (PHP) and the architecture of the system.

I think that many web developers would welcome a system with something like the types of plugins offered by WordPress, but built on a much cleaner language like CoffeeScript, Node.JS, BDD (not a buzzword, I mean specifically developing starting with Vows and Jasmine, those are actual specific libraries for BDD as per examples such as here http://vowsjs.org/) and a component architecture (I will explain exactly what I mean by that).

Components are reusable, interact on the basis of known interfaces, cohesive but decoupled, and substitutable pieces of software, which often, as in this case, present graphical user interfaces. I intended to use them primarily (but not exclusively) to compose the user interface screens and to provide easy configuration and integration for different aspects of the system.

Building the screens from drag-and-drop, composed components with on-screen configuration rather than using mixed PHP, HTML and CSS code provides a major advantage (obviously) for end users and also (perhaps less obviously for many, unfortunately) developers.

Having reusable, easily configurable components available with built-in UIs could make plugin and application development much more efficient for developers than it is with just (for example) libraries of modules.

I've been working on an OT implementation for the past few weeks. It really is some brain wrinkling stuff. The adoption of data-bining we're seeing in the newer JavaScript client frameworks/libraries could be paving the way for something like OT to go mainstream. OT is a bit like pulling your brain through a wormhole#. I think it's going to take a really easy to plug-in library to have something like OT get any traction.

# That is, OT is fairly straightforward if you're editing a document. It gets weird when you have to map a graph of objects onto/from a stream of operations.

  OT is fairly straightforward if you're editing a document

I think there is a better ROI on making the intent of your collaborators clear, such as with cursor/mouse indicators. If I can see you're editing a number, I can know to steer clear, or at least be ready for the consequences.

Getting OT-for-JSON working involved a lot of cases, but it was certainly tractable. The tricky algorithmic code is 440 lines long.

XML would be much more complicated to get right, but certainly possible if you're mad keen on XML.

Say you have an object:

{x:1}

Two people try and add a y:2 to the object. If you treat the object as a string, you can end up with:

{y:2,x:1,y:2}

... which is invalid JSON. If you do string-level operations, there's heaps of ways the JSON can end up invalid or just plain wrong. In comparison, using OT if two people apply a "Insert y:2 into the object" operation, the object will be edited correctly at all sites.

The canonical example of a text document with operations consisting of inserting or deleting strings of characters is a little error-prone, but in the context of humans editing text in real time, there's an assumption that they will correct any visible artefacts.

However, when you have structured data created and consumed by algorithms, your tolerance for artefacts goes down to nothing, and you need to choose a different set of operations and carefully design the transformation function.

In between structured data and unstructured text there is also text with semantics. As noted above, you can ignore that and leave it up to humans to fix it, or you can bake some smarts about the text in. There are existing products that treat numbers as a special case, for example. It may not be worth the effort, that's a design choice.

Anyhow, this is a lot of blowhardiness just to say that OT isn't an error-free way to synchonize strings, nor is it just one algorithm, it's a protocol and part of the design process is deciding when and how to go beyond plain text and the obvious transformations on the operations.

Also, plaintext and JSON data types are generic and pluggable into other systems. I'm not sure what you're trying to do, but they might be useful.

Socket.IO plus some kind of generic data framework with a collection type.. you can get pretty far with most CRUD type applications if you just have a way (something OT algorithms handle) to resolve issues related to positioning in a list I think, and that could be generalized to take care of everything from sequences of characters in text to items in a spreadsheet.

When you are talking about graphs.. what sort of issues are you having?

Now that I’ve seen it—I want everything to be real time and collaborative. I think it’s one of those things where once people have seen it, there’s no going back.

What did you like about it?

It's been a while but if I remember correctly, there was a slider on the top right with a play button. It allowed me to scroll through the history of the doc akin to Time Machine. That visual playful approach is much more engaging than a drop down list of versions. Titles and dates really tell you nothing about the nature of the document.

Watching an essay evolve with a click of a button was awesome and uniquely informative. A killer feature that should not be sacrificed. It was certainly a feature that could help Google Docs position itself above native applications.

There's no more clamoring each week for the powerpoint that I refuse to make. They're now using each other to build notes that are better than anything they could build individually.

When we get this technology into everything, the world will be a much better place.

Demo: http://sharejs.org/hello-ace.html

Github: https://github.com/josephg/ShareJS

Can it do OT on types other than text now?

EDIT:.. actually I see the JSON example. The hex thing game, I notice it has a fixed length in that array.. does this sharejs OT library handle cases where a variable size array has concurrent updates, deletes and inserts?

Also, ShareJS isn't limited to ace. Textareas work as well. Here's the same document that was linked, editable from a textarea:

http://sharejs.org/textarea.html

I'm not a rock star that knows how to optimize every slice of code.

However, when I go to other industries and bring my programming skills to improve their processes, I am basically a wizard in their eyes.

But you can make an amazing amount of money making people’s dreams come true in the workplace was well. How do you feel about Visicalc, fax machines, FedEx, and others examples of things sold to businesses that provoked the same “Why didn’t anyone think of this before?" reaction? Sure, people justified these purchases with the money they’d make or save using them, but often people looked at them, stared, then a lightbulb came on and they wanted them.

Businesses are staffed by people. Yes, you can sell them Enterprise Software and Services they hate, and laugh at me from your massive mansion. But you can also sell them software and services that make their dreams come true.

For example, the GUI basically turned accessing files (along with other commands) from mundane tasks into easy and attractive tasks, effectively making it far more useful by lowering the learning curve and lessening the complexity.

Movies are another example of turning something (plays) into a more exciting, entertaining, and accessible form.

It seems that what we consider "Dreamy" is simplicity. Perhaps that's why consumers gawk over Apple device's and describe them as dreamy. It makes one wonder, why is it that we consider simplicity so attractive?

One reason could be that it is purely natural human instinct. We do not like not understanding things and we constantly try to understand that which we don't. When people create things that increase other's ability to understand whatever product or service they are offering, they are creating desires, also known as dreams.

In a sense, that's the only reason that businesses exist, or at least it's the only reason businesses should exist.

Ever noticed how someone looks attractive from behind but then they turn round and are not so much? It seems to me that when our brain fills in the gaps it assumes that the subject is aesthetically pleasing. (Well, either our brain defaults to expecting something to look nice, or it fills in the blanks with an average and we find the average to be attractive.)

So coming back to simplistic design and why it evokes a positive emotional response from us: Perhaps it's because with a simple design our brain has more 'blanks' to fill in.

If anyone knows of a name for this phenomenon and further information exploring it I would love to learn about it. Same goes for if what I'm saying is nonsense and there is an alternate theory disproving mine!

Unless you find every person you see from behind first, initially attractive. But I know I certainly don't.