Latest News Posts

Social
Latest Forum Posts

Team Development at Cost Zero
Bookmark and Share

team_dev_at_cost_zero_102912
Print
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.

Team Development at Cost Zero

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.

Global Software Development

Initial Considerations

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.


  • http://techgage.com/ Marfig

    One quick note, in case the thought has come to you of using Microsoft Team Foundation Server, if going with the BizSpark program. After all, it does feature all of what is described in the article, with the exception of communications.

    It’s not usually a good idea. Team Foundation Server doesn’t scale well to small teams of developers. It’s an excellent tool for large teams or large and complex projects. But doesn’t scale down very well. It also requires a rather competent internet connection during peak working times. You could theoretically use TFS to replace one or another tool, like using it just for revision control, or bug tracking. But then you would just be installing a full-featured server tool for a single purpose. Not efficient.

    Much better is to plan for TFS (if indeed you want to use this tool as a central solution for your Application Lifecycle Management) after you exceed the necessary requirements. Ideally this will happen later in the finishing stages of your project, when you secured some sort of investment or partnership deal. At that time you could drop the current tools and move onto Team Foundation Server for all your ALM needs.

Advertisement