November 2008

We've been working on Dojo Learning for over a year now and we're progressing nicely towards a really major update we're calling "Dojo 2.0". It's still a couple months away, but we think we've got something that will definitely knock some socks off. I can't say any more yet, but we'll have more details on that soon enough :)

I've also been doing software development for about 10 years now professionally, so I've seen my share of what works and what doesn't. And I learned most of what doesn't the hard way.

But instead of officially employing a particular software development methodology as a standard here at Dojo, we simply try to practice a few informal principles in all of our thinking about Dojo.

Over the next few posts, I'm going to break those down and talk about each one. The first is about managing ideas.

Keep a list of ideas

This may seem like an obvious one to many, but a surprising number of people don't record their ideas and so those ideas simply come and go.

We have a huge number of ideas for new features and improvements to Dojo Learning. We record them all to a big list and revisit it periodically. Most of them will likely never see the light of day, and many end up being solved indirectly anyway (I'll get to that later).

The important thing here is just to keep a list, to keep adding to it, and make it accessible to everyone so they can add to it too. And any time a user suggests something, put it in the list.

We also keep a list of ideas that don't fit the project, but may be things we branch into later, or that pieces of what we've made before can be used towards solving.

You never know where an idea will lead, so jot them down. This is the easiest thing you can do, and gives you an endless supply of material for future brainstorming and planning sessions.

If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.

Here are some thoughts on our API and APIs for Software-as-a-Service companies in general that I wrote in an email recently and thought they might be worth making public.

API in plain English

API is a programming term, which stands for Application Programming Interface. An API is a way of accessing your data directly, instead of going through our website in your browser. A developer or administrator could use it for example to do regular backups themselves, to export data into another application, or to build an entire application outside of our site itself.

We have a few ideas of our own that we'd like to build on top of our API, but essentially it opens things up for customers and enables many possibilities that we may not have thought of ourselves.

Content ownership in software

We see this as very important since content ownership needs to rest with the customer, not with us (the service provider). This has always been a big issue in software, not just with SaaS services, but SaaS does change things up.

Traditionally, proprietary software used proprietary file formats, meaning that while you had your files, you were still locked into their file format, and so you had no choice but to use that software, or change with some difficulty. The Open Source software movement helped change that by raising awareness and by ensuring the code and also the data formats were open and interoperable.

Where SaaS changes things

The problem with the traditional software model is that by installing software yourself, you bear the burden of maintaining that software and the machines it runs on. For complex software, this often requires a full-time system administrator to be hired.

Software-as-a-Service solves that by letting us be your software host so we take care of the technical details for you, which can save a company lots of money, but it can potentially put your data into a closed scenario again.

So customers should be careful to make sure any vendor provides a means of accessing the data in a way they can take with them, that way the control and ownership rests where it belongs, with the customer and not the vendor.

Future interoperability

Over time, I believe standards will continue to develop and be adopted by SaaS companies too, and I think it's in everyone's best interest for that to happen.

Just like today OpenOffice.org can import and export Word files and new file standards are emerging for office documents, so too will ways of standardizing data formats for more specific applications like e-learning. And in the meantime, if we all do our part to make sure customers maintain clear ownership of their data, then we ought to be well poised for a future where customer relationships with SaaS services are built on quality, value and trust.