Jordi Cabot is a post-doctoral fellow at the University of Toronto and creator of the Modeling Languages portal. Greg Wilson is an Assistant Professor in the Department of Computer Science, University of Toronto, and editor of Beautiful Code. He He can be contacted at http://www.third-bit.com.
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 like SourceForge or an installed system like Trac, in many ways that portal is the 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.
Since dozens of portals exist (or partially exist, or may have existed but are now moribund), we had to decide which to include in our study. Our initial pool of candidates consisted of systems that one author had examined when selecting a portal to use in undergraduate software engineering courses. We enlarged the pool by conducting web searches for keywords prominent in those systems' descriptions of themselves, by including systems that previously-added systems compared themselves too, and through word-of-mouth referrals from colleagues and attendees at various conferences. The list was then filtered again according to the following criteria:
- The system had an active developer community.
- It was being used by people other than its developers.
- Many or all of its users were software developers using it for software projects.
- Someone central to its development was willing to be interviewed. We did not request contact with specific people but instead asked for interviewees playing a key role in the tool conception and development (founders, CIOs, chief developers or similar). To our pleasant surprise, only two of the groups we approached declined to take part and thus were removed from the study. (Due to confidentiality issues we cannot identify these two tools nor provide more detailed information about the names and exact roles of the people we interviewed.)
With these criteria, our final list of portals was:
Having selected these systems, we itemized the features offered by each in the areas of authentication, collaboration tools, document management, work tracking, and time ma nagement, and where feasible gave it a test drive to validate and fill in gaps in their self-descriptions.
We then set up an interview with a key member of its development team. We originally intended to conduct hour-long structured interviews, but interviewees perceived their systems and markets in such different terms that no question script made sense for everyone. We did, however, cover all of the following areas:
- When and why did you start developing the portal?
- Why did you decide to create a new portal instead of adopting or extending an existing system?
- What user needs did you set out to satisfy?
- What was your initial business model?
- Does the portal favor any software development process?
- What software development process do you use yourselves?
- Who are your typical users, and how do you determine their requirements?
- How do you determine user requirements?
- Is it open source, closed source, or some mix of the two?
- Is it free to use or not? (This is orthogonal to the open/closed questions, since some groups provide a free service on top of closed-source software, while others offer a stripped-down version under an open license and a premium version with extra closed-source features for a fee.)
- Is the portal deployed as a hosted service, do users have to install it, or are both options available?
- Can third-party tools be plugged in by end users, and if so, how?
- How do you see the portal and the market evolving over the next couple of years?