There is a lot of interest in dotWRK. Would it be wise to take the above into account and share planning and/or resources even at this stage of development? I could see dotWRK reworking the acs_subsites, while dotLRN finishes reworking portal, etc. In the end OpenACS 4.7 gets out the door faster, as well as dotLRN 2 and dotWRK.
If it isn't already obvious, I'm still interested in dotWRK, but I would prefer that it was based on what I see as the fundamentally better idea of dotLRN 2.
Whether that is a separate package, dotLRN related stuff back-ported into oacs or something else is of course open for discussion.
In case there's any doubt: I'm not trying to force the *result* in any particular direction, I'm trying to force the *process* in a particular direction.
And so far a lot of people seem to have slightly different ideas when they hear 'dotWRK' - we need to resolve that first before we jump into solutions for yet vaguely defined problems. This thread is meant to get everybody explicitly on the same page.
As soon as there are some more posts I'll do another summarization attempt.
This may not be practical for thesis work on PM, however. So, running the first two phases in parallel may work best.
Can I interprete that as 'taking the general bits out of dotLRN and put them into a package on their own'?
In that case I couldn't agree more. Question then becomes what bits should be taken out and how to be repackaged?
Logical things could be:
- the portal stuff (already a separate package)
- generalized version of 'community' (i.e. departements are communities, project-teams are communities, ...)
This is exactly my question - what functionality should go in the 'umbrella' packages and what will eventually be dotWRK.
There's already preliminary planning going forward to complete OF's rewrite of the new-portals package - this came up in another thread, and Michael Hinds will be putting together an estimate of what's required, and if it's not too overwhelming may get the go-ahead from his employer to finish it as part of a project they're working on. I'll be coordinating with him on this, and/or doing a bunch of the work (originally I was planning to do it myself)
I've been working slowly on laying the foundation for getting subsites into shape and in 4.6.2 things will be in considerably better shape than was true in 4.5/4.6.
OpenACS already provides a solid generic group management facility - please study the groups and relational segments datamodels and supporting code. dotLRN provides a good working model for how a vertical application can use these tools. The problem in OpenACS per se is that there's not a practical UI for making use of these facilities in our subsite package. Lars Pind has the design of a new UI on his plate. My personal thinking has been to map role-based access control onto the group/relseg datamodel - the datamodel supports more sophistication than this but I think for a standard subsite package, role-based access control is something that's fairly easy to define a good UI for and is something that users will find fairly easy to understand. Packages or vertical apps needing more than this probably won't map to a generalizable solution that will make sense anyway, IMO, but since the datamodel is so general custom group management code is easy to to write.
The current OpenACS acs-subsite admin UI actually lets you do this (well, in 4.6.2 you'll be able to do this, since some of the bugs/quirks in the code have been fixed), it's just incomprehensible, that's all.
My recommendation is that the dotWRK folk concentrate on applications for the time being. Since the portal system simply maps templates to portlets, it's often possible to share template chunks between your portlet and non-portlet pages that provide views of data. So if you get the application right, generating portlets will be very simple in general. Maybe a day per portlet, something like that.
And on the application side I'd recommend concentrating first on the datamodel for the various pieces. How do we want to represent the various resources within an organization and how do we want to tie them together? I think the calendar package is a great example of what happens when too much effort is expended on writing code that provides pretty displays and far too little effort is spent on designing the datamodel.
Let's not repeat that mistake!
There's a lot of application code that needs writing before dotWRK can become a reality. By the time a dotWRK group makes significant progress in this direction I think you'll find that the issues in the bullet-list that heads my post will be solved in the general toolkit.
Of course, dotWRK will undoubtably want to layer custom UI on top of standard portal management and group management facilities that already exist, but that's a different issue ...
The issue is this covers a range from an intranet (meeting room/ lecture theatre) which room reservation meets (even this the package exists in a number of forms, as it was part of the aD bootcamp exercises)
a fullblown booking system supporting say a squash court, with various levels of priority players (comp players get higher priority than non members, say).
From my point of view, all these core facilities fall under the dotWRK hat from a "use case" and "push" perspective: We need it for dotWRK, therefore Jeroen and others can help clarify the requirements, use cases, and people who need dotWRK will be well positioned to develop this.
That doesn't meant that the code should live in some dotWRK package, or that it should be specific to dotWRK in any way.
Concerning the discussion UI vs. solid design. I would start with looking at the needs and what other vendors usually offer and what their users have to say in terms of wishlist. Just an example: In what way should dotWRK make the use of MS Project obsolete. Concerning HR, let's take a look at SAP, how they are handling the HR basics (I don't think anyone in the community would like to remodell ALL the business logic behind the SAP R/3 HR module).
Now, who is going to do this? I'd love to see some stakeholders popping up their heads saying, yep, I'm gonna write up a preliminary feature list and put it out for discussion for a specific issue. Once we have these lists we can move forward and discuss the common features and other ideas on integration.
Though having verticals is a nice idea, I think we should delay this unless client driven. We should first cover our basics before moving on to other areas. Well, and take into account that especially when it comes to verticals, we need specialists in these areas to achieve anything useful.
I'm not entirely sure about it, but my gut feeling says we would have a tremendous advantage, if we could access the SAP BAPI's through the toolkit and display most often wanted information within portlets on the website. Good item for university projects, but clearly something which will take some time (and some > 6 months).
An while talking about integration, having access to Lotus Notes databases wouldn't hurt either.
Malte, I envision building a program (ie. large scaled project) cost estimating, scheduling, charting, and coordinating capabilities (call it "dotSystem") into OpenACS for manufacturing/development cycles, operations management, and building construction starting with top-down metasystems modeling and methodology. You're right that these are long term goals.
Adding a statistics package will be a critical component. [I was going to suggest adding a statistics package for dotWRK on a previous post but really think it should wait until dotLRN is folded back into OpenACS with the dotWRK goals currently outlined --to save duplication of efforts. Also, I wanted to refer to the postgres statistics package that a couple of OpenACSers are playing with... but can't find the forum reference about it right now.]
On another point, there seems to be a behavioral pattern within the OpenACS community to wait until funding before starting on such a long-term endeavor. Doesn't this assume that MBAs etc. will seek such a solution from OpenACS, or that OpenACSers will be able to sell it to them before making it?
I have great confidence in this community. Still, isn't the MBA culture much different than opensource's gift culture? I think the efforts needed to sell (compete) would be enormous. [Yes, there are MBAs who do not follow the MBA cultural values as implied and generalized here, and who would choose OpenACS. One of my best friends is one. I don't mean to offend anyone, just be matter of fact about the cultural values in general for purposes of discussion.]
One MBA rule implicitly states that paying for development work is generally much more risky than paying heaps for an existing (therefore predictable) solution --ie. the Oracles and SAP's will "win" on these terms for all large projects because they already have solutions.
Yet, I believe these terms ignore the potential of the open source culture to create effective solutions for meeting the demands for dotSystem capability outside of the enterprise business environment (as well as in it).
As long as long-term goals do not impinge on short-term, similarly aligned objectives, I see no reason to wait.
On another point, there seems to be a behavioral pattern within the OpenACS community to wait until funding before starting on such a long-term endeavor. Doesn't this assume that MBAs etc. will seek such a solution from OpenACS, or that OpenACSers will be able to sell it to them before making it?Right you are
There are of course other potential buyers beside the MBAs, like institutions and NGOs for instance.
Since we (the companies and individuals in the open source comunity at large) develop code that is free (as in speech), it would probably be a pretty bad idea to write the code, publish it, and _then_ ask for money, if that is what we're after. I mean, when the code is published it all of a sudden becomes free as in beer ...
In fact, it's not the code (a product) that we charge for, but the work we perform (a service). Open source is a gift culture in the sense that you give away the product, but not necessarily the work. It is an "open source" culture, not a "voluntary work" culture. Voluntary work is evidently (and thankfully!) very common within open source, but it's not the essence of it.
We should keep in mind that the open source movement as a whole is a rather new thing. We are still pioneers in this space and it remains to be seen how it matures commercially.
My guess is that more and more of the MBAs out there (and especially the ones yet to come) will open their eyes and embrace this new culture, which is indeed quite different from what they're used to. When they realize the influence they will get on the final product, and the opportunity to take it in-house, etc, I'm convinced they can't refuse it .
Until the average MBA gets used to the concept of open source I think the open source companies will just have to approach customers already committed to the cause, or, prepare themelves to spend large anounts of time on research and on marketing their proposals.
We are building a vertical app that also requires tight integration with stastical functions. Right now we are using a numerical library written in C and calling the statistical functions from PL/SQL using Oracle's external pocedures. If there is a way to something similar that is not Oracle specific we would like to try it.
Our company is interested in a lot of these applications. Scheduling is one that we've discussed recently, for example, and we'll probably use anything that works for us that we as a group build. I'll probably focus initially on project management and task management (tickets).
I don't really see anything preventing us from starting to build these applications now. We just need to coordinate how we'll work together to get it done, and make sure the parts work well together, no?
Still, Lars may have a point imho when he says "all these core facilities fall under the dotWRK hat from a "use case" and "push" perspective". While defining the requirements for the various applications I guess the dependencies to (currently) dotLRN related stuff will become clear. By that time we can signal this to the relevant group (Don - do you represent the 'relevant group' in this case?)
So the new question-of-the-day seems to be - what applications, in what order and who's gonna do what?
For sanity sake - let's start with 'what applications'?
In the doc I posted I'd already listed a couple of apps that seemed to be wanted, based on the various forum posts.
Giving the 'people' list another look shows that project mgmt. type of stuff is firmly on the number one spot.
In this category I think of applications like:
* project repository (i.e. CR for projects)
* project scheduling & reporting
* collaborative todo-list/task tracking
* resource management
* timekeeping (linked with scheduling and task-tracking)
* holiday booking (idem)
* expenses (idem, budgets)
* messaging (chat, im, mail)
* wiki (i.e. general purpose information sharing)
* document storage
Some things may already be available - I guess.
I wouldn't mind working on wiki (currently playing with dave's code) <off-topic> - on the wiki topic, what is is your [Jade] opinion? I saw in the wiki-thread that you were in doubt whether to adopt Dave's code or the extend some other wiki package? </off-topic>
Anyway, From a logical point of view, if we like Nick's 'project repository idea' (do we?) it would be most sensible to implement that one first before project scheduling and task-lists (in fact - if you define a project to be a collection of tasks and people tied together by a schedule, then a collaborative task list is just a project without a strict schedule, isn't it?)
But I'm losing focus: lets first see what applications we want.
Project Repository is needed by:
-- Project Scheduling
-- Project based todo list
-- Resource Allocation Management
-- Expenses (at least in most cases it makes sense to link them to a project)
Scheduling is needed by:
-- Project Scheduling
-- Task / Todo List (for keeping track of due dates)
Resource Management is needed by:
-- Time Keeping
-- Holiday Booking
-- Todo List
If you agree with this aproach, we could have a closer look what we need, which tasks need to be done first and then find the people to work on the tasks in a given order. My assumption is, once we have the project repository and the resource management ready in the basics, other packages could be developed in parallel.
BTW - I think there're actually more dependencies:
Project scheduling requires:
-- timekeeping ('already used' time can impact the schedule, especially if it is more than planned :(
-- task/todolist (and phasing - lets not forget that! Very important for projects)
-- resource allocation
-- holiday booking
If you add it all up then the workorder would likely look like this:
1) project rep (indeed the most fundamental)
2) resource manager
4) phased/categorized task/todolist (a normal tasklist simply has one phase)
5) timekeeping, holidaybooking, expenses
6) project scheduling
7) project reporting
Why would folks want to add "a way to define portal templates" to a work list when this already exists?
Now ... there's a lot of work left to do to move relevant pieces of dotLRN back into OpenACS and in some cases to generalize it, and of course the existing admin UI for group/role management is so obscure and obtuse that I may be the only person who understands that it provides this facility. Lars has the design of a new admin UI on his plate, and if dotWRK folk want to help implement it or help with the UI design why sure, that would be fantastic.
I just want to make sure that people understand which of the necessary pieces already exist in some form. When I see a work item labelled "solid generic group management" it's not clear to me whether the person writing this understands that OpenACS 4.6 simply lacks good UI for this, or whether the person writing this believes that there's nothing in the toolkit that provides generic group management.
As far as the list of applications you're developing - I think it's an ambitious and exciting list. It would be great to see people working on such things.
And the current calendar datamodel sucks for this.
So a root dependency would seem to be "rewrite the calendar datamodel so it is easy to map arbitrary content to calendars".
There have been threads about this elsewhere but it doesn't hurt to make the need for this for dotWRK explicit in your list of dependencies.
My response to Jeroen's question about Wiki's is here: http://openacs.org/forums/message-view?message_id=86000
Don: very good point about calendars. We did this piecemeal for ACS 3.4 (because we needed it), and I've thought for years about how nice it would be to have a calendar that could easily map ticket deadlines, room reservations, project meetings, etc.. to dates.
So the calendar module should also be a pretty foundational part, I agree.
Jeroen, I'm glad you have project management experience! This looks like a good example project! Let me see, dotWRK is the project, there are subprojects, building all the foundational datamodels, and other subprojects which depend on those subprojects, such as actually building the applications. Then we have tasks, which we'll take on, which will have deadlines... ..............
I think the current ETP, new-portal, bug tracker (configured as ticket tracker) and workflow applications are strong candidates for going into a dotWRK configuration.
In some items below I may very well be pointing out the obvious, however I still want to highlight those ideas and tasks so that they are not overlooked at this important point when the dotWRK project plan takes shape.
Search is very important.
So we really want a unified search package, that can use OpenFTS on postgresql and Intermedia on Oracle. This allows package authors to provide content via service contract and not worry about what database is being used.
Along with this, we need to add package specific, package type specific, and object type specific searches.
The search should probably also allow searching in categories through integration with a general category system.
These are all OpenACS specific items that will greatly enhance any site, but are definitely important for a dotWRK project.
(I'm not implying he's wrong about technical comments, he's just the first to bring up - dare I use the word? - marketing points)
It would be really great to get a logo put together soon, and to use it on the project pages in order to differentiate them from the generic openacs.org part of the site, such has already been done for dotLRN.
I don't understand why the content in question doesn't derive from acs-event. The whole point of a service like acs-event is to generalize.
Can you give me an example where you wouldn't be better extending an event? I guess I just don't see it, and I hardly use CR, so I have no point of reference.
To me one of the biggest problems with calendar is that a cal-item can only be on one calendar. This makes it difficult to share an event with only certain people.
If acs-events has any downside it is that it is to flexible, it was modelled to allow arbitrary events with arbitrary start, stop times and durations. I think many people are scared by it. (not impling that you are, just in general). I still see people writing thier own events packages that don't use acs-events.
Anyway, with respect to competetive analysis, we could start here http://www.adtmag.com/article.asp?id=7349 and here http://www.adtmag.com/article.asp?id=7350. Although may be a little OT - see below for simpler examples.
Then, more than anything else, KISS!!! From the packages mentioned in articles I've worked with Primavera and MS-Project. Both are feature-loaden, but for most projects at least 50% is rarely if ever used and even doing simple things can be difficult.
PM tools are administrative tools, mainly to help you rembember what you otherwise would've forgotten, help you to reduce the mesh in your head, to confirm your gut-feel and to communicate that gut-feel to others. But that's just my view.
I'd say let first get the basics right:
- proper work breakdown structure
- simple scheduling of tasks within the wbs
- a risk/issue register
- proper support for interdependent projects (i.e. ability to have projects containing subprojects)
- links between timekeeping, holidayplanner & plan
- may be a GANTT or PERT chart
- sensible resourcemanagement, linked to timekeeping and wbs/schedule.
- some collaborating tools (e.g. shared filestorage, wiki, forum, ...)
That way you cover the basics pretty well, and more sophisticated things can always be added later as an add-on package. Especially if we go for the 'project repository approach'.
But why not post it as a question in alt.projectmgm and/or alt.comp.projectmanagement. Expect a lot of flaming/off-topic remarks (like 'why would you do that' and 'pm is not about the tools', etc.), but we might get some sense out of it.
Another source of information are of course related projects such as (note - I did not put those links here as 'this is how we should do it', most are actually terrible, just a peek at the competition):
http://www.achievo.org/ (I've used this before, and it's actually very usefull, bit limited though and not that easily enhanced)
http://mrproject.codefactory.se/ (desktop (X) app, very simple but effective for simple projects)
A couple of them are open-source, so we might consider looking at how they work as well.
One thing our company will likely need is the abiliity to associate structured data with each project. For example, details on the product (if the project is product related), and who in the graphics department is working on it, etc..
It's probably a little early to be making comments like this, however.
I've found this article on the MS Project 2000 Database Format. Describes a bit about the MS Project datamodel... even has a bit on calendar data. I'm not suggesting to use this datamodel, but to keep it in the back of our minds for when we decide to import/export MS Project data using XML. MS Project allows project data to be exported to XML. I can't find the XML schema just yet, but this will allow us to import MS Project data into our proposed "project repository", and conversely export to MS Project.
Someone mentioned are we planning to replace MS Project. In short... no we are not. MS Project is an application used by PMs to schedule, plan and monitor a project. But is it the right tool to be used by all members of a project team? The project tools that we want to develop for dotWRK should allow project team members to update their "actual" progress. This will allow the PM to compare the differences between "estimated" duration and "actual" duration, and if the project is not on track, then the PM can take the appropriate course of action to get the project back on track. With this sort of project reporting (from team members) at a micro level, the PM is able to estimate Earned Value more accurately as well. This kind of feature will make the dotWRK PM tools quite powerful, as the progress of a project becomes more transparent.
My vision of the PM tools for dotWRK is a fully integrated suite of PM tools. This can be achieved through a unified data model, as proposed for the "project repository" package. There are very few PM tools that are fully integrated. Those that have used Rational tools will know where I am coming from, as they are not fully integrated, and do not exchange data between applications very well. (A possible marketing avenue to explore?)
In designing the project repository package, we need to establish a datamodel that will encompass all data associated with a project. Secondly, an API needs to be designed to allow other applications to retrieve or modify project data. Finally, we need a web interface to administer this package, with sample use cases such as creating and initiating a project. I'm working on a project specification document that will better explain the purpose of this package.
Sorry if the below sounds a bit like a rant - it's not meant that way :)
""" In short... no we are not. """
I agree, but for different reasons.
"""MS Project is an application used by PMs to schedule, plan and monitor a project. """
And that is indeed the job of the PM, although I'd say replace 'monitor' with 'control'.
""" But is it the right tool to be used by all members of a project team?"""
No - and they're not supposed to. The tools in the kit that are for 'them' are things like documentrepository, (collaborative) todo/task-lists, timekeeping, perhaps chat/forum/wiki.
The wbs, scheduler and nice views are for the pm to maintain. They may see them of course, but should not touch them.
""" The project tools that we want to develop for dotWRK should allow project team members to update their "actual" progress. This will allow the PM to compare the differences between "estimated" duration and "actual" duration, """
That won't happen. Only way you can get project members to report accurately is to link it with the timekeeping system and link the timekeeping system with their payroll. And even then :(
""" and if the project is not on track, then the PM can take the appropriate course of action to get the project back on track. With this sort of project reporting (from team members) at a micro level, the PM is able to estimate Earned Value more accurately as well. """
How many projects did you lead where 'reporting at a micro-lvel' actually worked? In my experience pm is 80% communication. If you /need/ the tools to tell you what went wrong, you should not've been the pm in the first place imo.
For that particular reason it's important to keep projectteam size within you max. span of control - typically not more than 10-15 people (for an experienced pm that is). If it gets bigger, divide in subteams and manage the subteams/subprojects, not the people or the whole project. And at that stage you get a project that consists of interdependent subprojects, where the teamleaders maintain their own schedule, which you incorporate in the main one.
""" This kind of feature will make the dotWRK PM tools quite powerful, as the progress of a project becomes more transparent. """
A clear plan of approach, good reporting, having a well maintained risk register make them transparant. Micro-level updated GANT-charts don't.
Then why do I agree with "we're not replacing ms-project":
- indeed because of the collaboration-angle
- and it's too bloated. Having a good foundation on top of which we can build more advanced stuff later (i.e. when there's actually demand for the advanced stuff) is far more valuable imo then the everything-but-the-kitchen-sink approach.
What I meant by "reporting at a micro-level" is having developers report their effort spent on a task upon completion. I was coming from a software project management angle, as I have worked for a company developing software project management tools. Some of our clients were defence contractors that were trying to achieve a higher CMM level, and therefore had mature software processes in place. Maybe I was thinking too far ahead, or beyond the scope of what we want for now.
I wasn't referring to "micro-level updated GANT-charts", I was referring to improving earned value estimates with micro-level reporting. I'm not sure if earned value analysis (budgeted cost of work performed) is commonly used in Europe, but its heavily used by US and Australian departments of defence in software projects.
I agree that we need to develop a good foundation. Perhaps more general PM tools are required, and not ones focused on a specific domain such as software project management.
In fact, I think that would be fairly elegant. That way each time a person gets assigned a task, be it in the context of a project or in an operational context he's instantly able to book time on that particular task. By making the UI intiutive, it doesn't matter to the user whether they book on projects or on tasks. Whether or not you use that kind of detailed info is another case, but then at least it's there.
On a related topic: I was thinking a bit further about my own remark about posting something in alt.projectmgm etc. Could we perhaps setup a survey to 'poll' for what people think of as 'the ideal set of tools'? Not that we should build that - just to get ideas.
Or, Nick, have you already encountered such a thing?
Sometimes authors can provide quick experiential substitutes for surveys when they summarize norms (and limits).
Here are some comments from Eric Verzuh, author of "The Fast Forward MBA in Project Management: the portable mba series" published by John Wiley and Sons 1999, page 281 to 285 quoted and summarized below:
"No matter which kind of project information system a company might choose, there are a number of considerations that will influence the effectiveness of the system and the effort to install it. Here are some guidelines for developing.. [one].
"Start with reporting requirements... the information requirements for the system must be clear. The basic questions that drive the entire system are:"
"Who needs information?"
"What information do they need?.. what decisions or actions will be based on the information?"
"When do they need it?"
"Where will the information come from? does it exist anywhere now or does it need to be created?" there is a need for consistent standards for entering data at the detail level (pg283) [It seems that an ability to assign to any instance (financial, calendar, resource, content) with at least one WBS reference (which designates responsibility and authority roles etc.]
suggests "top-down design of a work breakdown structure"
Customization is a given part of any off-the-shelf system
"if your organization runs many small and medium-size projects, you'll want to use the simpler applications at the project level. These lower-end applications may not have enough power to pull data together from all the projects, however; you will need to choose one of the high-end applications to handle that chore" [I think this implies ability to dump data to spreadsheets or external DBs for starters]
a pm system only works if it gets used consistently and completely --ie users don't bypass it, suggesting that the system needs to be user centric and user friendly.
"The true potential of a consistent approach to pm is realized only when the discipline is extended to the organizational level and used to choose, monitor, and cancel projects. The ability to link projects to the operational and strategic goals of an organization has far-reaching implications for the effective use of resources, particularly people."
"Like good pm, portfolio management delivers the best results when it is based on facts and data. The project information system empowers the portfolio management process by providing the facts that drive decisions".
"The Spectrum of Project Office Models... The two factors that govern a project office role are responsibilities and authority (full, partial, none). [Hmm. this granularity should adapt well to the user-group permissions in dotLRN (as I understand them)]
I think these comments suggest some rudimentary customizable resource/info sharing packages that where hinted at previously. Since OpenACS' strengh focuses on collaborative work, I don't know that it would be wise to model after non-colaborative pm-based software solutions, given that pm systems work best when the entire project team participates. These packages need to be user-centric while providing the pmgr with the necessary operating info also.
I'll see if I can make an abstract and post it on the project page.
It seems to me, with my limited experience in project management that we have a structure like this:
Project A - Manager AA
Project B - Manager BB
Project C - Manager CC
Inside Project A:
Start date: April 1, 2003
End date: June 1, 2003
List of subprojects:
List of tasks/tickets:
Task aa - assigned to abc, deadline April 15, 2003
Task bb - assigned to bcd, deadline April 30, 2003
Task cc - assigned to cde, deadline May 15, 2003
Task bb can't be completed until Task aa is completed.
Each employee has a list of tasks/tickets. They work from those tickets, and have the ability to update the deadlines (of course this sends an email notice to their manager and anybody who has tasks dependent on theirs).
Whenever they close their tasks, or change the deadlines, they make comments on what they've done. This is in fact micro-level updating, and not by the managers. The managers are certainly able to do this, but the team members themselves are able to manage their tasks.
The managers thus get a list of projects, and can look at gant charts, see what's happening on each project, etc.
The employees get a list of their tasks, and they can click on them to see more information about the project, and what depends on their task being completed. The employees work from their task list/ticket list, and mark each task as closed when it is completed.
Does this make sense as a work case scenario?
I'm pretty new to formal project management, but this is the scenario we're thinking of at my place of employment.
We're already doing this using the old ACS 3.4 intranet, and it works okay, but it needs to be reworked greatly to REALLY do project management the way we'd like.
Just a thought
It's really a pity - I've seen the dotWrk pages only a few days ago. Even Dirk Gomez didn't know about them. So I think I have duplicated some efforts...
I'm working on a similar project since June 2003. I started as a project management system for a local translation agency (http://www.sls-international.com/ - someone needs _high_quality_ translation into Spanish? . Briefly checking for alternative system, I decided to go ahead with the old ACS 3.4.8 Intranet that is in productive use at Competitiveness (http://www.competitiveness.com/) with a few enhancements. So I spent the summer customizing the system and building a reasonable business solution.
Telling a few friends about the project and showing them the new GUI, they encouraged me to widen the scope and to actually design a "Project Resource Planning" platform, providing support for several vertical modules (Hi Malte!). So http://www.project-open.org/ popped up into existence.
Recently things got even a little more encouraging. I managed to convince a student from Universitat Politecnica de Catalunya to write his final thesis about building a translation marketplace module for Project/Translation and La Salle University approved a Knowledge-Management workgroup, staffed with 4-5 final thesis students. They are going to use Project/Open as their development base.
So the idea is starting to convert itself into real systems. I'm planning to publish some press releases as soon as I've got a reasonable demo system online.
The drawbacks of the system are its ACS 4.5.8 base, its lack of multilingual support and the restriction to Oracle. And I had to customize the platform quite a bit, in order to get a new fine-grained permission system working (http://www.project-open.com/whitepapers/).
Code is currently not available publicly, because Project/Translation contains customer owned code. The current "Project/Advertizing" project with Opus 5 (http://www.opus5.info/, currently my first priority) will lead to a modularized system and the release of a "core" module and an "advertizing" specific extension module. I hope to finish this reorganization around 11/2003.
A lot of things are still open to discuss or clarify:
- Is Project/Open going to be a separate project, just using the ACS/OACS platform, or is it going to be integrated into OACS?
- How to design the relationship between dotWrk and P/O?
- How to deal with conflicts between the open-source idea and commercial interests? What does the history of ArsDigita and the current state of the OACS system teach us? How to integrate "business guys" into "the community"?
- Is OACS going to take over some of the P/O concepts, such as the fine-grain permission model and the configurable views?
- ... and many more.
Anyway, I think the follow-up discussions should take place in another thread, not to trash the great contibutions above...
Just referring to "fine-granied permissions" I can't imagine any situation you could not model with the existing permissions data model in OpenACS.
=> Please don't reply to this message
I've created another thread, called "Announcing Project/Open" in ACS Development. I think it would be a great idea to continue the discussion there.
Actually, I created two threads (fuck, I think I'm getting old...). I've marked one of the threads as invalid. It would be great if somebody with admin permissions could delete it to avoid confusion.
Dave, I'm still developing with ACS 3.4.8 and I have to admit that I'm not familiar with the current OACS permission model. My permissions forms a matrix between user profiles (managers, project managers, employees, accountants, freelancers, clients, ...) and permission to modify business object such as view_freelancers, edit_freelancers, add_freelancers. Check it out yourself (http://www.project-open.com/whitepapers/ and "Permission Model"). And let's continue the discussion in the other thread, ok?