Date: October 29, 2012
Author(s): Mario Figueiredo
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.
Collaborative development has become ingrained in the minds and practices of software developers everywhere, to the point it’s no longer a buzzword. A large part of the software being developed today has been completely or partially done by programmers over a network across long distances.
Three things have greatly contributed to this: the Internet ubiquity and the advancements in bandwidth offerings, the rapid development of specialized tools and services for programmers wanting to share work across long distances, and the increasing complexity of the software required by users.
It’s unquestionable that the great motivator and contributor to this software development paradigm has been the open source community. Most of the advancements in tooling and development practices concerning collaborative development has come from that group. This activity stems from the fact that open source development is almost exclusively done by large groups of developers across the globe. The Apache project includes developers from five continents, all contributing source code from their homes or work places.
However, collaborative development has also become an integrated part of closed source development. Not to the same scale, for sure. But it’s been a practice among hobbyist and small developers in pursuit of creating free and commercial products. Likewise, companies large and small have been collaborating on all types of projects, either through contractual partnerships or through subcontracting. Interestingly enough, the current landscape of collaborative software tools and services presents a problem to small teams of developers wishing to collaborate over closed source projects.
A good portion of the collaboration services available on the Internet are free. These primarily include revision control and bug-tracking tools. However, these websites do not generally allow the hosting of closed source projects – when they do, it involves paying a monthly fee. These groups of programmers are often ad-hoc partnerships between individuals, with very little monetary resources, no investors to speak of and no company formed, wishing only to create a product before they commit to the legal and fiscal unpleasantness of creating a company and a brand name. Essentially, individuals with no money to speak of, but still wishing to give it a try like everyone else.
What this article presents is a complete solution for collaborative development of small team projects at no cost, past what is already there with the Internet access bill.
Explaining every step of the procedure is unnecessary and outside the scope of this article. The aim is to expose the available options. It’s assumed that the reader knows what revision control, bug-tracking or Apache is and how they need to be set up (or at least know how to learn from the many online manuals and tutorials). There is however, a comments section to this article linked at the end, and I will be more than happy to answer any questions there.
The core of the whole setup is the local installation of revision control, bug-tracking and database management services that will serve the team through the Internet. An ad-hoc website will also be installed and a communications solution presented. Most of this will be server software. ADSL Internet connections aren’t ideal for this type of setup, considering the great limitations they usually impose on the upload link. Ideally, one will want a DSL, cable or fiber connection, and any team member having such a connection should be considered as the prime candidate for installation.
With small teams (2 or 3, maybe 5 programmers at most) it can work reasonably well if installed over ADSL. In any case, it is recommend that the team share responsibilities instead of everything being installed on a single member machine. One member is responsible for hosting and maintaining the revision control service, another bug-tracking, another the database, et cetera.
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.
Bug-tracking comes a close second in the list of most important achievements to software development technology. It provides the means for project development organization and filtering. It’s an essential aspect to team development since it greatly reduces communication noise between team members by committing all of the software development stages and requests to a centralized database.
Bug tracking operates as a software development-oriented issue tracking system. Modern implementations are developed as three-tier client-server applications and include project management features. The presentation tier makes exclusive use of the Web browser. So, in order to implement the team bug-tracking system we need to combine a database server and a Web server.
This is best achieved by making use of any of the available solution stacks on the Internet. AMP (Apache, MySQL and PHP) is a well-known general-purpose solution stack that comes on the three major OSs, LAMP for Linux, WAMP for Windows, and MAMP for Mac. We are going one step beyond.
Bitnami offers zero-configuration, software-specific stacks. Among them you get a choice of three well-known bug-tracking systems. Trac, Redmine and Mantis are powerful solutions that will answer most, if not all of your requirements. The Bitnami stacks for these include all that is required to install and get them up and running at full-speed in no time. It’s your choice to choose the best stack for your team.
Trac uses Python, Mantis uses PHP and Redmine uses Ruby on Rails. The latter can be considered more visually attractive and easier to use, while the others are more feature-rich. If you wish to use some other bug-tracking system, you can install a general purpose stack like WAMP and manually install your bug-tracking system of choice. Apache Friends offers very complete and easy-to-install LAMP and WAMP stacks, or you can go with Bitnami infrastructure stacks. You should also take care to check them against the revision control system you chose above. All include hooks to notable software revision control systems, which greatly improves what you can do with a bug tracker system.
The next step is making sure the whole team has access to the bug tracker client. The solution stacks above do not require any Apache Web Server configuration for a local installation. However, for team members to access it, you should give the necessary permissions and open port 80 (or any other port you choose) on your computer. Since it is most likely that you will be connected to the Internet with a Dynamic IP, you also need to somehow emulate a Fixed IP to simplify access to the Web server, otherwise, you would always have to inform the team of your IP address every time your router acquired a new one.
For this we make use of the No-IP service. With it, it’s possible to emulate a fixed IP address in a dynamic IP configuration. It includes a small client that you should install on your computer, which monitors your current external IP address and maps it to the No-IP fixed address that was assigned to you. The service also includes, if you so wish, a subdomain of your choice which will allow your team to connect to the webserver by using a familiar name, instead of an IP address. For instance, http://YourProject.no-ip.com/BugTracker/.
If you want to use port 80, but your ISP blocks it or redirects any requests to its own Web server, No-IP can solve this if you make use of the Port Redirect feature. This shouldn’t concern you if all Apache is doing the serving for your team. If you want it to host content for people outside of your team (perhaps a project webpage with contact information you can link to potential business partners or investors), No-IP could be used to simplify access to your Web server as well.
This is the closest you can get to a full Web hosting account without paying a single cent.
By now, you have a fully operational revision control and bug-tracking system. All your team members are able to connect to them and make use of them. We haven’t spent any money doing it and you may begin to feel that this is all that is required. Technically, there isn’t much more to it. There’s also the aspect of the database management system which we’ll address briefly below, but essentially the primary building blocks of a good team development strategy are in place. It’s for this reason that it’s easy to overlook team communications.
In a modern Internet with e-mail, instant messaging and IRC, you may feel this isn’t worth discussing. A matter of fact is that keyboard-based communications are extremely clumsy solutions in a development environment where often complex ideas and thoughts need to be exposed in a clear manner – who knows, sometimes while coding. Likewise, it’s very hard to run a team meeting on IRC or IM for the simple reason it can’t really replace the rich communication that happens in a real-time debate where all people are present in the same room.
What you need to ensure is a way for the team to communicate by voice (which is our richest communication medium) and through a hands-free solution. For this we are going to use the free TeamSpeak client. At no cost, TeamSpeak provides access to numerous servers where you can setup a private room that all team members can join. Everyone can now truly communicate in real-time. There are other clients that may be used too, such as Mumble or Skype.
Naturally, all other mediums can still work. E-mail, IM or IRC are all still valid solutions. Particularly important when there is a need to persist what is being discussed. But for real-time communications you’ll find yourself using more and more, something that allows you to communicate better and faster. This is an essential aspect to team software development, as important as anything else we’ve discussed so far.
If the team is developing an n-tier solution, there will also be the need to install and setup a database server. There isn’t much that can be said about it. Between Oracle, MS SQL Server, MySQL or PostgreSQL, all include the necessary features to be accessed over the Internet.
However, particularly during the data modelling phase of the project development, a database server can impose a great burden on the upstream link when every team member is trying to access it at once. Later on, the same can be true when anyone coding the top layers makes large queries on the database server.
For this reason it is best, if possible, for every team member to install their own local copy of the database server. They should either set them up for replication against the team member responsible for database management or perform only manual synchronizations (perhaps through backup/restore). When developing against the database, one should use their local copy.
Later, as the project comes to an end, it should be a simple matter to change the connection strings. During development though, just make sure to keep local copies of the connection strings and not include them in revision control. If you do, get your team to install their local database servers to the same relative path.
This section is exclusive to Windows development and Microsoft development frameworks.
Usually, team development at this scale and for this purpose happens because all team members already have access to the tools needed for development. If you are developing by making exclusive use of open source or free tools and frameworks, there shouldn’t be a problem hooking your team up with all of the required tools. However, if you wish to develop against private frameworks and with commercial tools, you will surely expect your team to be fully equipped on their own.
It may not be so all the time, or you may wish to make use of rapid-changing technologies (which one isn’t, really?) and want to ensure that during the whole development process you and your team have access to the latest versions. You may think that, this being the case, you are out of luck. How can you possibly have free access to MS SQL Server and Visual Studio Ultimate, for instance, and not just one license but as many licenses as you have members in your team? Well, you can.
For years, Microsoft has been running the Microsoft BizSpark program. This program offers start-ups and entrepreneurs access to a 3-year free MSDN Account (expansible to your team members), technical support, and access to business incubators, investors and a whole network of potential business partners. It’s the perfect setting to not just get free access to all of Microsoft’s operating systems, software and development tools, but also take your project to the level where you can actually market it, trying to secure the interest of a potential business partner or investor.
To be eligible, your business must be privately held, less than three-years-old and making less than 1 million USD in annual revenue. You’ll be required to sign-up a Microsoft Account, if you haven’t one already. You will also be asked about your business website, which you can set up as a single webpage in your Apache Web Server installed above, if you wish.
However, you may have noticed that I said you are required to have a business. Something that you and your team may not want to do at this stage. BizSpark seems to give some allowance on this matter. Just be completely honest about the nature of your endeavor when contacted by a BizSpark account manager and all should work out. If not, you should weigh your options. Particularly take a deep look at the options available in your country when it comes to starting a small business. Do not make assumptions. It’s my experience that you’ll find it easier than you may have initially realized. Many countries put a whole lot of effort in creating the best conditions for entrepreneurs and the creation of businesses at zero cost.
For development teams not completely aware of all of their options, a zero-cost setup may seem unlikely, if not impossible. But as this article has proven, it’s not only possible, but the number of options is huge. Your zero-cost setup may be different than someone else’s – what’s important is that there’s bound to be a perfect solution out there for you and your team.
Discussed just above, BizSpark is another solution that many don’t realize exists. If you’re a Windows developer, having access to all of Microsoft’s development tools and operating systems can prove invaluable to your progress. Having access to BizSpark is like being given thousands of dollars to spend on software; the difference is that it’s free with the caveat of a three-year time-limit.
From setting up a server to bug-tracking, we’ve covered about all there is to for small team development. If there’s a point you are lost with, or you have further questions, please post in our thread below. Also, if you’ve gone the zero-cost route yourself in the past, we’d love to hear about the route you took.
With that, happy developing!
Have a comment you wish to make on this article? Recommendations? Criticism? Feel free to head over to our related thread and put your words to our virtual paper! There is no requirement to register in order to respond to these threads, but it sure doesn’t hurt!
Copyright © 2005-2021 Techgage Networks Inc. - All Rights Reserved.