Forum OpenACS Development: Re: Announcing Project/Open

Collapse
Posted by Jade Rubick on
Frank, I'm impressed with what you did with Project/Open.

Perhaps you can have a look at project manager, and start thinking about how you're going to upgrade, and what functionality we will want to merge together?

My one concern is how you're going to merge together the very specific functionality for translation with the general needs of a project manager. Perhaps you can break some things into separate packages..

Collapse
Posted by Frank Bergmann on
Hi,

important question. Modularization keeps me awake at night... (no kidding). I just have started a project with Opus 5 (http://www.opus5.info/) to adapt the system for them. And with the Knowledge Management stuff I'm going to have three "vertical solutions", each with quite some different requirements.

First, I need to separate the sector specific functionality into separate modules, because I don't want to clutter my stuff he same way as it has happend for example with the old BBOARD (with this geospacial stuff from www.scorecard.org). Second, I need to define a common "core" (common to all vertical solutions), that needs to be highly configurable to cover the needs of the different vertical solutions. Right?

So I'm already preparing the core to allow for "pluggable modules" that attach to ProjectViewPage, CustomerViewPage and HomePage (for example as one of the grey boxes at the right) plus menu items, libraries, data model and module specific pages. But I'm still thinking about a suitable API. Currently, I have "views" already factored out. That is: The columns in ListPages and the rows in ViewPages are defined in the database.

create table im_views (
      view_id                  integer primary key,
      view_name                varchar(100) not null unique,
      visible_for              varchar(1000),
      view_sql                varchar(4000)
);

create table im_view_columns (
      column_id                integer primary key,
      view_id                  not null references im_views,
      column_name              varchar(100) not null,
      -- tcl command being executed using "eval" for rendering the column
      column_render_tcl        varchar(4000),
      -- for when the column name results from an "as" command
      -- for ex., you can customize viewing columns
      extra_select            varchar(4000),
      sort_order              integer not null,
      -- set of permission tokens that allow viewing this column,
      -- separated with spaces and OR-joined
      visible_for              varchar(1000)
);

This allows to select different views for different user profiles or different views for the same ListPage, used for example in /intranet/projects/view.tcl, which shows either a standard project list of a "status". It allows clients to customize views, without having to fear to loose these changes when upgrade the TCL pages to the next version. It also allows other modules to add "their" columns to a ListPage (for example, the "invoicing" module may add acolumns "$ invoiced" and "$ received" to the ProjectListPage).

Concerning the integration P/O <-> PM:

First of all, Project/Translation would go without project manager. That's easy. They always follow the same workflows. It's actually a pitty to call that "projects". What they really need are configurable workflows, where you can assign freelancers to each of the stages, and upload/download large cuantities of files.

Also, Project/Advertizing would go without project manager, because advertizing project typically don't have such a "rich" internal structure (compared to IT projects). And most advertizing PMs seem to be - to put it in friendly terms - less willing to tightly structure their projects. At least that's my experience. They just have a very different concept of a project than we techies.

Project/Consulting (IT-consulting!) would definitely profit from a more detailed project structure. One option would be to plug the project manager it into the P/O framework, to handle the scheduling and internal structure of a project. Obviously, that idea comes from my side ... 😊

The cruical question is: How to handle duplicated business objects, particularly projects. However, we've got some time to think about this, because I first need to get some business. Otherwise Project/Open is going to die in January. Atleast my participation...

Finally, there is another consideration to the module issue. I have to admit that I'm planning to distribute sector specific modules under a licence different from GPL. I like stuff to be free, but I need to make money to go on. So I don't want that other consulting companies are going to make their money implanting free modules. Instead, I would allow end users (_employees_ of the end user companies) to use the stuff for free, but to charge any external consultants 20% of their fee if they are helping to implant free P/O modules. This may (hopefully!) lead some day to a marketplace of software developers and implantation companies...

Don't crucify me, please! 😊
Frank

mailto:fraber@project-open.com, http://www.project-open.com/