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.