by Mario Figueiredo on October 29, 2012 in Staff Editorials
Many Web services provide open source teams with an infrastructure for collaborative development, but what if you’re a small team of developers with little funding wanting to develop closed source software? Can you still engage in collaborative development while keeping your costs minimal? Yes, of course. We show you how.
It’s impossible to overstate the importance of revision control in modern software development. Maintaining full history of the project’s various stages of development is perhaps the most important breakthrough in development practices ever devised. Even lone programmers use revision control for their projects and it has long ago moved past the software development industry and into other areas of production.
File hosting services are meant to share and synchronize files between different computers across the Internet. The services act as storage gateways allowing anyone to connect to them and without any other intervention, synchronize the contents of their shared folders in real-time. The transparency level at which the service works is remarkable and makes it ideal for this purpose. SkyDrive, Google Drive or Dropbox are possible solutions. These are free file storage services with enough reputation to guarantee some piece of mind against data theft. But read on.
Whether you use a centralized revision control system like Subversion, or a distributed system like Git, you will most likely want to have a central repository. That will be the one you want to share. The idea is to create the repository in a convenient location on the hard drive and then set up your file hosting service of choice to share the repository top folder among the other team members and their computers.
Team development at this scale is rarely about shared responsibilities. Usually, every member will be assigned their own area of the project and normally won’t commit against someone else’s files. Branching and merging is a rare occurrence, left only for carefully designed steps of the development process. As such, centralized revision control seems a natural choice. On the other hand, distributed revision control is still some sort of black art among developers not accustomed to open source development. It is possible that among your team, some developers aren’t knowledgeable about this type of revision control and haven’t yet gone through the paradigm shift.
My advice is to make the decision in a two-stage process. The team should first default to a centralized revision control system. The two most important considerations; if everyone in the team is knowledgeable about distributed revision control, or if the development strategy for the project will include a good deal of branching and merging. If any of these are true, then a distributed revision control solution is what you should choose.
The file hosting service will also require some careful thinking. Of the three services suggested here, Google Drive has been the one coming under the most fire from users and experts alike, due to the seemingly vague nature of the company’s terms of service, as well as the fact that Google allows itself to retain user files even after they have deleted from the respective accounts.
However, SkyDrive and Dropbox aren’t much behind, being often criticized for similar or whole new reasons. SkyDrive specifically imposes severe restrictions on the type of content it allows to be hosted, with some users having already seen their accounts shut down due to “inappropriate content”. This suggests Microsoft actively monitors and inspects a user’s files on SkyDrive.
At first glance, Dropbox seems to be the service of choice, and that’s my personal suggestion. There’s very little in Dropbox’s terms of service that differ from Google Drive. But the major two differences are important: Files deleted will stay deleted and it won’t use anyone’s files for anything else other than what is expected as part of the service. Above all, it should be clear that we get what we paid for – these services are free. Under a no cost obligation, relying on a 3rd party’s free file hosting service will invariably put a burden on any privacy and copyright concerns.
To be sure, there’s a couple of other solutions that don’t involve the use of a third-party service. The repository can be installed on a local machine and made available through SSH. One will of course need an SSH server for this. There are various flavors of FTP too, something like FileZilla server can support FTPS, which is SSL-based.
For Windows, freeSSHD is a good option that can serve both SSH and SFTP. Alternatively, since an Apache is likely to be installed, one can set up Apache and WebDAV to serve the repository. This last option is a complex one to setup however, and it will vary between revision control systems. It should only be considered by someone with good knowledge of both Apache and WebDAV.