Sourced from Dr.Dobbs.



If you pick a software development project at random, the odds are good that its source code, bug reports, mailing list archives, and so on reside in a web-based portal. Whether it's a hosted service likeSourceForge or an installed system like Trac, in many ways that portal isthe project: individual developers might come and go, but the portal's contents live on, and with them, the project.



Despite their widespread use, software project portals have been studied much less than individual-oriented tools such as integrated development environments (IDEs) [IEEESoftware08]. To begin to rectify this, in July--September 2008 we examined the features of several representative portals and interviewed their developers. Our research goals were to determine what needs those tools were intended to serve, how their feature sets had been chosen (e.g, how their developers had translated perceived needs into functionality) and how they were likely to evolve. To our knowledge, this is the first general study of web-based software project management tools, though their importance was pointed out in [Alshawi03; for comparisons of pre-web tools see [Terry98].



We begin below by describing what a minimal portal might contain. We then explain how we selected and collected data about 11 specific portals. The remaining sections analyze our findings and speculate about the likely future evolution of software portals. It is important to note that for every system we included there were several others that we left out. Our choices should therefore not be taken as a judgment or recommendation.
 

What's (In) a Portal?

 


Just as programmers may use "editors" ranging from Notepad through Vi to Eclipse, so too do online project management tools range from shared to-do lists to multimedia collaborative environments. To be called a software project portal, however, we felt a system must have at least a few specific features. The first is some kind of task management, such as a to-do list, bug tracker, or full-blown workflow management system. For us, this is what makes project management tools distinct from other kinds of groupware.



The second core feature is a document repository. Systems aimed primarily at developers typically integrate a third-party version control system such as Subversion, while systems aimed at broader audiences usually include a simpler file upload mechanism. Both allow stakeholders to share and modify content, and to see who else has done so.



Conversational tools are third on the list. These include email, chat, wikis, blogs, bulletin boards, and other ways for stakeholders to communicate and coordinate. A growing number of systems present content in several forms, e.g., by providing RSS notification of updates to bulletin boards, or wiki transcripts of chat conversations.



Last but not least is search. One reason people use portals is to link the disparate pieces of information that comprise a project; one of the benefits of doing this is that a single query can then find email messages, version control check-in comments, and wiki pages all at once.



Other components tend to revolve around these four core capabilities. For example, some include a calendaring tool so that stakeholders can schedule work items (e.g., by grouping them into iterations, and then binding those iterations to target delivery dates). Others include time-tracking tools to help consultants with billing and schedule management; a tagging mechanism; a report generator; a web API for remote scripting and administration; customizable fine-grained access control; or a continuous integration back-end to automatically re-build and re-test code. As with document repositories, these may be more or less developer-centric, i.e., may require greater or lesser degrees of technical sophistication to use.