Taking a solution from the Open Source community

Sam Hart

2009-09-02 22:36:37

Fortunately for the Indie developer, these problems have already been addressed by another community that is used to working in highly distributed ways. The Open Source* community.

Open what now?

Defining Open Source is well beyond the scope of this article, however we can give some key bullet points that are relevant to the Indie developer.

• Open Source software is generally developed by large groups of developers working in extremely distributed and ardently uncoordinated ways (well, compared to traditional closed-source development- Open Source purists will argue that they actually develop in a more coordinated way, but it's ultimately all relative :-)


• Open Source software is generally developed with tools that not only strengthen the distributed development model but also reward developers who work with them in such a way.


• Open Source software typically winds up being gratis, or free as in "no cost". This means that you can use them without having to pay anyone.


• The Open Source development model is generally a meritocracy, which means that the "best" code typically percolates to the surface and you wind up with some very good software.

Open Source development is really a philosophy coupled with licensing and development models. As we said, a full explanation is well beyond this article. If you're curious and would like to know more about it, then we'd suggest Googling for the topic.

Distributed Version Control Software (or DVCS)

Version control in software development deals with tracking and managing changes to software project files over time. There are many reasons and advantages for doing this, but the ones we're interested in are:

• Gaining the ability to rollback changes


• Gaining the ability to fork a project directory to develop a new branch (revision, version, whatever)


• Track the changes that various developers make to the project

Traditional Version Control System (VCS) choices include tools like CVS and SVN. VCSes work on a client-server model where each developer runs a client that communicates their changes back to a server which holds the project. VCSes do work well in distributed development teams, however they have a number of important limitations:

• They require a central, canonical source code repository where the source code lives. This means that:
  
  • You have a central point of failure
  
  
  • If someone breaks the code in the central repository, it can easily break the code for everyone
  
  
  • One developer can block the work of other developers by blocking/locking the central repository
  
  
  • You can't work on the repository "offline" (you may be able to work on the code, but you can't do anything involving the repository)


• Complicated merges can block the central repository. This means that if two different developers try to commit code that results in a conflict, it can block the central repository until the conflict is resolved.


• VCSes require significant coordination between the distributed developers.

Because of these problems (and many others), a new type of version control system has recently gained popularity (especially in Open Source circles). It is called a "Distributed Version Control System" (DVCS**) and has a number of key differences over classical VCS:

• No central repository! Instead, each developer/user has a full-fledged repository for the project on their local disc. This gives you many benefits including:
  
  • In a distributed project, no single point of failure!
  
  
  • Developers can work 100% "offline". Sitting on an airplane with your laptop? No problem, you can work on your code, fork it, merge it, branch it, rollback changes, etc and so on without any sort of internet connection


• Merges become effectively peer-to-peer, which means that complicated merges will only adversely affect the people involved in the merge (no blocking the work of others)


• Repository changes are fast as they are effectively only working on the local repository


• Developers can work asynchronously

---

[*] : Technically, "Open Source" isn't a terribly descriptive term- in reality it's an umbrella term that describes many different licenses and development methodologies. For example, when most people talk about "Open Source Software", what they really are talking about is "Free Software" as the Free Software licenses tend to be the most widely used. There is a great deal of controversy when talking about "Free Software" and referring to it as "Open Source". I have intentionally glossed over this in my document simply because it is a complex and politically charged debate that isn't terribly important to my intended audience. Unfortunately, it is easier to explain what "Open Source" means to someone new to these concepts than it is to explain what "Free Software" means in this context. Personally, I find this distasteful as I am definitely of the "Free Software" mindset, but I long ago learned to just not fight it when I'm trying to get a tangential point across :-)

[**] : Alright, more controversy I'm glossing over. Depending on who you ask and how you phrase your question, you will find a large number of different names for what I am calling DVCS (as well as what DVCS stands for). Personally, I prefer "Distributed Version Control System" and the "DVCS" acronym, so that's what I use in this document.