Saturday 29 September 2012

Design for Fork and the liquididy of OpenSource/Git

If you are designing an application that you will share the code on GitHub (open source or not), the most important advise I can give you is to 'Design for Fork'

What I mean is that the idea of 'creating a fork (or clone) and starting a new instance of the app' should not be something that is left to the Open Source Gods, as in '...hey the code is available so you can go out and run your own instance...'.

If your app is not 'Fork/Clone Friendly' then it will always be a pain to deploy and use, and you will be missing a very key mechanism to keep complexity at bay. Deployments should be measured in seconds/minutes and with only a couple clicks required.

Maya talks about Information Liquidity in their Trillions concept where information is supposed to flow like a liquid and be able to move over rough , uneven or new surfaces by being liquid. Note that although there is a common carrier on any liquid (water/H2O) there are lots of different types of liquids (i.e. information) that can be carried, packaged, exchanged, consumed, etc...

This is liquidity is exactly what we should aim to get from Open Source or GitHub repositories. Its code AND content, must be easily consumed, exchanged, manipulated, modified, etc...

For me, this concept is not something theoretically, it is something that I put in real practice while developing TeamMentor and the O2 Platform

One of the areas of TeamMentor that I'm more proud of, is how the latest version is very light to install, deploy and set-up (the only requirement is .NET 4.0 and in some cases IIS ). There are no databases to install/configure, the source code is included with the deployment, the content/articles is all stored on XML files and we use Git/GitHub not only as version/control control , BUT as a distribution medium.

The idea of storing the content on the filesystem is very important since part of making your data liquid is to have NO database (as in MSSQL, MySql, NoDB, etc...).

My recommendation is to store the data on file system (as files) and use GIT (and GitHub) as your database. You will not create something more powerful and flexible than Git and it is a very scalable and robust solution for content control.