Note: this post expresses the personal opinion of Pietro Polsinelli. The opinions expressed may be highly biased, but told with no hypocrisy, as is customary in blogs.

Solicited by an evaluator, I took a look at one of our competitors: the @Task application. (call it @T from now on).

The first unconfortable thing is that on the site there is no hand on demo. So I had to enrol just to look at the flash “presentation” (strange), which gives little information, apart from many big words. So I also read all the PDF on the site, and looked the screenshots.

Differences of power

Looking at the screenshots, their task model seems simple minded; in lists, the search filters seem poor, considering those in Teamwork, which allow QBE and its combinations.

The sentence (from the site) "Create Access level, Company, Project, User" seems symptomatic of @T not being really role-based, but again with "hard-coded" security. Permissions are set directly on the task, and not through assignments: Teamwork is far more flexible on this.

There does not seem to be any period events management. The agenda interface seems less user friendly than that of Teamwork; again it seems to have only a fraction of the power of Teamwork schedule model. Teamwork’s skins are also prettier.

Document management doesn’t seem to integrate with the file system as Teamwork's file storages.

There is an underlying difference of approach: take the notion of “approval”: can this be met by introducing simply a field with a user who approves? This is an incredibly simplistic approach: approval can be as complex as a task; what if more then ONE signature is necessary? It is much better to have a dependency from an approval task, or even more, to connect the task to a workflow definition which captures also approval.

Another example: to customize pages, we included a complete content-management system in Teamwork 3: I strongly doubt that @T has this power; our portal features are hard to beat.

More generally @T "feels" a "hard-coded" application. It is not clear from the documentation if it supports arbitrarily deep task and resource trees (Teamwork does indeed).

A difference in modelling power can have big consequences in time; what can be trivial in a general model, can be impossible in a restricted one.

Some ideas seem plainly wrong like having "Profitability reports": profitability is so subject to variations between companies and even between projects that it can be only evaluated by having the task give you the plain costs; only a human with the costs in hand can evaluate the real profitability.

It is probably a difference of basic philosophy: @T is focused on standards, Teamwork on modelling power.

Application integration

1) For application integration, the fact that Teamwork is Hibernate based, an open and by now dominant technology, is surely a plus. @T seems to support natively only

* Oracle,
* Microsoft SQL Server 2000
* MySQL

while Teamwork supports

* Oracle 8i, 9i, 10g
* DB2 7.1, 7.2, 8.1
* Microsoft SQL Server 2000
* Sybase 12.5 (JConnect 5.5)
* MySQL 3.23, 4.0, 4.1, 5.0
* PostgreSQL 7.1.2, 7.2, 7.3, 7.4, 8.0, 8.1
* TimesTen 5.1
* HypersonicSQL 1.61, 1.7.0, 1.7.2, 1.7.3, 1.8
* SAP DB 7.3
* Apache Derby
* HP NonStop SQL/MX 2.0 (requires Dialect from HP)
* Firebird (1.5 with JayBird 1.01 tested)
* FrontBase
* Informix
* Ingres
* Interbase (6.0.1 tested)
* Mckoi SQL
* Pointbase Embedded (4.3 tested)
* Progress 9
* Microsoft Access version from 95, 97, 2000, XP, 2002, to 2003 (requires Dialect from HXTT)
* Corel Paradox version from 3.0, 3.5, 4.x, 5.x, 7.x to 11.x (requires Dialect from HXTT)
* flat text , CSV file, TSV file, fixed-length, and variable-length binary file (requires Dialect from HXTT)
* Xbase database (dbase, Visual DBASE, SIx Driver, SoftC, Codebase, Clipper, Foxbase, Foxpro, VFP(3.0,5.0,7.0,8.0,9.0, 10), xHarbour, Halcyon, Apollo, Goldmine, and BDE) (requires Dialect from HXTT)

:-D

2) Teamwork can be integrated with a real workflow engine (JBPM)

3) No trace of sources of @T to be found; Teamwork’s persistent model is on Sourceforge.

Finally

The impression from the website is that @T is a quite poor application, but its few points are presented and stressed again and again (again lack of live demo suggests this), so it has a strong commercial support.

We could make a deal with our customers: we'll reproduce any report that @T does in Teamwork for free, if it is compatible with the data model.

Last but not least, we are very competitive on price:

  @T: $395/User plus a 20 percent annual maintenance and upgrade fee
vs.
  Teamwork: 10Euro/User with no expiry

Hence, imho, we cost less, and give more.