This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Reviews

OpenProj: good software, but needs documentation

By Joe Barr on February 26, 2008 (9:00:00 AM)

Share    Print    Comments   

OpenProj 1.0 was recently released by Projity, which offers a related commercial product called Project-On-Demand. OpenProj is written in Java and licensed under CPAL 1.0, and versions for Windows, Mac OS/X, and Linux can be downloaded from SourceForge.net.

CPAL -- the Common Public Attribution License -- is a relatively new open source license, submitted to the Open Source Initiative for approval last July. It is recognized by the Open Source Initiative as an open source license, but the FSF has not yet classified it. In spite of its approval by the OSI, I found the license difficult to parse, and recommend you have a lawyer review it so that he can advise you on what you can and cannot do with the application and the code before making a major investment of time and effort working with CPAL licensed code.

If you've ever been involved as part of a team doing traditional software development, you know how important it is to track and report progress towards the final goal. Milestones, deliverables, deadlines: management wants to know all about them. The problem is that often management doesn't speak geek, so they need to be fed the information in easy-to-swallow charts, graphs, and high-level reports. They say geeks like shiny things. It's equally true that management likes pictograms. A good project management tool handles the translation with ease.

OpenProj -- designed as a replacement for MS Project -- can produce all the graphic reports you're likely to need: Gantt, RBS, WBS, and Network Diagram (PERT) charts, Histograms, Resource Usage, Task Usage graphs, and even a project report.

Unless you are already familiar with similar applications, it may be a struggle for you -- as it has been for me -- to become adept at using OpenProj based on visiting the skimpy project documentation available thus far. You can learn a lot of things by simply clicking Next when the Tip of the Day appears at startup-time, but that's really not a satisfactory way to answer a question that comes up when you're actually using the program. Here's one of those tips: There are tons of great sources of Project Management information on the Web. OpenProj is very similar to existing commercial solutions.

Another, and more useful, tip that I found by clicking Next (Tip of the Day) again and again is If you press F1, you'll get online help for the item underneath the cursor. If you're viewing a Gantt chart of the current project, for example, and press F1, the online Gantt chart documentation will appear in your browser. Another tip based on my own experience is to join the OpenProj wiki where the help documentation lives, and then use the search feature to zero in on needed instruction.

I created a software development project using seven people and lasting one month using OpenProj, often by hit-and-miss due to the lack of a guide. OpenProj asks you at startup if you want to create a new project or work with an existing one. If you select create, you're asked to complete a brief form about the project. Then you're on your own, looking at the blank Gantt chart shown in Figure 1.

The first thing I did after creating the project was enter resource data about the seven individuals who would be working on the project: a manager, analyst, three developers, and two testers. An easy chore, given that the data is typed directly into the resource form, as shown in Figure 2.

The next chore was to enter the basic tasks required for completion from a fairly high-level view: planning, requirements analysis, design, design review/signoff, development, testing, and repair/acceptance. Once those tasks were entered, I assigned the needed resources to each of them by first clicking on the task bar in the Gantt chart, then on Tools->Assign Resources on the menu bar. That presented a list of all the resources I had entered earlier, and I could click on an individual or range of individuals and then click Assign.

Removing individual resources from a task is done the same way, but I ran into either a bug or a documentation barrier while doing so. Deleted resources would not disappear from the Gantt chart until I saved the project file and then reloaded it, leaving me uncertain if the delete action had worked or not.

OpenProj lets you link tasks together with the mouse. Simply click-and-hold one task and then move the cursor to the second. Links can be defined as FS (Finish/Start, which is the default value), FF (Finish/Finish), SF (Start/Finish), or SS (Start/Start). Simply click on the link itself and a pop-up window appears which lets you change the link type from a drop-down menu, specify a lag time, or remove the link entirely.

The last thing I did was to create a baseline for the project for future progress to be measured against. With the Gantt chart in view, I clicked on Tools -> Tracking -> Save Baseline. The default is to save the baseline for the entire project, and that is what I did, but you have the option of saving a baseline for a specific task as well.

Correctly or incorrectly -- it's hard to tell without a comprehensive guide -- that at least got me to a starting point for tracking project progress and generating a bevy of reports along the way. The downside is that in spite of the many features which provide ease of use in OpenProj, you have to figure out how to use it step-by-step. Perhaps this would be a smaller barrier to those currently using MS Project. I can't speak to that. I can tell you that OpenProj can import MS Project files and is also supposed to be able to save projects in a format MS Project can read. I've tested the import ability by Googling for .mpp files, downloading them, and opening them in OpenProj, but without a copy of Microsoft Project I was not able to test the export function.

 

Conclusion

 

OpenProj appears to be a full-featured project management application, but its usefulness is impaired by the lack of documentation. Users are fed tidbits of help but there is no guide, no reference manual, and no tutorial. I was able to enter a simple project involving only seven people, but I don't know that I've done it correctly, or what else I can do with this program.

It appears to me that OpenProj is capable of a lot more than I've been able to exercise in the few days I've been looking at it, so don't discount the applications abilities based on my lack of skill with it. Blame it on the missing manual.

According to Projity CEO Marc O'Brien, more documentation is on the way. He told us "We are actually coming out with a big update to the documentation next month. The community is helping which is nice!" I hope that works out, because as it stands today, while OpenProj is not "crippleware," it is "walking-wounded-ware," and without good documentation, it is likely to stay that way.

Projity has opened the source code for OpenProj. Now we have to see if a community will form around it to make it a useful, viable open source project.

Share    Print    Comments   

Comments

on OpenProj: good software, but needs documentation

Note: Comments are owned by the poster. We are not responsible for their content.

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 75.117.39.137] on February 26, 2008 11:41 AM
The first red flag is the CPAL. This is like the Zimbra ZPL/YPL and it is not helping them right now. Zimbra is being threatened right now by a hostile
buyout offer from Microsoft through their attempt to purchase Yahoo. Microsoft can/will kill the project and no one will be willing to continue it under a
different banner because the trademarked logo is married to every single page throught the application and cannot be removed/replaced due to the license.
You cannot replace the trademarked logo so no forking unless you are willing to leave the logo and link to their website even if they become defunct or devoured by Microsoft.
This is why it is known as *badgeware* and the CPAL promotes the undermining of the spirit of FOSS.
No one will continue the project if this happens and what this means that any CPAL/badgeware license you chose does not offer the protection of longevity if the project
dies or is gobbled up by MS or other entity.

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 91.75.70.10] on February 26, 2008 02:03 PM
I guess it was written for people with some experience in project management, which apparently is not the case of the reviewer.

#

Re: OpenProj: good software, but needs documentation

Posted by: Joe Barr on February 26, 2008 03:03 PM
Sadly, a lot of people equate software project management with the abillity to tweak a software reporting tool, rather than having a clue as to how to design, code, test, and implement software.

#

Re: OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 87.211.186.131] on February 27, 2008 05:06 PM
Because (project) managers are generally known to be experienced software users?

#

OpenProj: good software, but needs documentation

Posted by: Vasily Tarasov on February 27, 2008 04:17 AM
The article refers to Figure 1, Figure 2, Figure 3, but where are they? I can see only one figure, which is probaly Figure 3.

[Modified by: Vasily Tarasov on February 27, 2008 04:21 AM]

#

Re: OpenProj: good software, but needs documentation

Posted by: Joe Barr on February 27, 2008 12:45 PM
Thanks for catching that. I've added Figures 1 and 2, and removed the reference to Figure 3.

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 70.54.109.8] on February 27, 2008 01:17 PM
Joe, project management has nothing to do with implementation/architecture/design. The best implementer/architect/designer in the world may still be a bad project manager. A project manager's job is to control scope and ensure that the things that people promise are done when and how they were supposed to have been and ensure that the right deliverables are released at the right time. It's hard work that requires more diplomacy and being "the bad guy" than anything else. Of course, you don't need a Project Tool to do that job, a spreadsheet may be enough. Linus is a good example of what I mean. He was a bad project manager in the 2.2 and 2.4 days where things slipped because Linus tried to be the nice guy. He's now quite a good one in the 2.6 days because of his regular releases that refused to slip and his organization of a strong freeze date before each release. It seems like a simple job, but it's hard.

#

Re: OpenProj: good software, but needs documentation

Posted by: Joe Barr on February 27, 2008 03:21 PM
I'm curious. How do you see project management being different in the world of free/open source software versus traditional proprietary/closed development? What tools work across that divide, if any?

#

Re: OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 87.211.186.131] on February 27, 2008 05:10 PM
'Joe, project management has nothing to do with implementation/architecture/design. The best implementer/architect/designer in the world may still be a bad project manager.'

Programmers may not make the best managers, I agree. However, that doesn't mean a manager may not make/is not a good programmer.

'A project manager's job is to control scope and ensure that the things that people promise are done when and how they were supposed to have been and ensure that the right deliverables are released at the right time.'

Which requires knowledge of said phases to understand what is possible, what is not and the risks that come with those actions. Otherwise, you might as well have a tape that repeatedly broadcasts a voice that goes "Work Harder! Finish within the deadlines!" I hope you're not a project manager. And if you are, I hope you're not as clueless on those phases as you make me want to believe project managers are.

'Linus is a good example of what I mean.'

Linus is a terrible example of what you mean. He started as a programmer, and he clearly understood the complications of implementation/architecture/design before he got to be an effective manager.

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 192.75.165.28] on February 27, 2008 06:06 PM
Depends on the project and project management style. The three main types are feature driven, time driven, and ad hoc.

Most people tend to gravite towards ad hoc, which is usually why procrastination and project delays happen so frequently and why you often
get into the situation where everything is 95% finished for the last 6 months but nothing is really there yet, but it will be "real soon now"
once I get to these other two must have features.

The other two work well, but only if you're hard nosed about either schedule or feature creep. I personally find the time driven appearch easier
since you can always tell the customer (we'll add your feature in the next cycle but let's get a solid foundation that's usable now) than feature
driven because schedules tend to be longer and because of this, so the pressure to add "just this one feature" tends to lead towards feature creep and
unless classic Debian-like release slippages.

From my perspective there is just two differences between the two:
1) Resources
a) Open source projects face the same problems any volunteer run organization does. You may not have enough people who need to do a critical part of the project and even when you do, there's no guarantee that they'll do what they promise.
It's very tempting, to let people off the hook (especially if it's an understandable family emergency) or give people other chances (after all, they *are* volunteering and you may not have anyone else),
but if they're on the critical path and their work is important, you'll need to give their work to someone else who can do the job (without loosing volunteers) or make contingency plans so that their work (any any work that depends on them) may be removed. Inspiring your volunteers is also important or they'll lose interest and give up.
Overall resource management is extremely hard for such projects.
b) Corporations have a much easier time at this. They either have the resources or they don't, and if you don't, you need to put it in your project plan and plan contingencies. The key issue is not resources or getting people to do their jobs
but lying to yourself, your customers, and your bosses. The lying isn't always intentional. Sometimes you or your resources want to be a "good guy" and take on more
that is possible (especially if this is only one of many projects) and sometimes you or your resources want to look good or believe you can rely on some other
resource which you can't. A good project manager here needs to be very hard nosed and be able to say "NO" when a schedule is impossible because of resources, especially
when those resources are a lie or someone else says "Don't listen to him, I can do it in half the time", and must find ways of getting all those involved to be realistic and come up with reasonable alternatives or compromises.

2) Risk/Accountability
a) Open source projects, except at the beginning, really don't have to worry about being strict with their schedule. Perl 6 is extremely late. Who cares,
Perl 5 is still good. Ditto for Debian. Sure things go stale after a while and competitors come into play (Ubuntu wouldn't have existed if Debian
had regular releases), and you lose motivation, but it's not that fatal as long as your foundations are solid and you have good maintenance of
the previously released project.
b) With corporate projects, you're getting paid to deliver and people's jobs (and sometimes safety or money) are at stake. Delays must not happen.
To use a non-software example, imagine that you bought a house that's being built and will be finished on June 1. You've rearranged your life
and made all the necessary irrevocable arrangements to move on June 1, but the house isn't finished and won't be for another 5 months. To you,
it doesn't matter that there was a strike and a shortage of lumber and a flood. You and your family *need* that house and the project manager
is to blame because he didn't plan all the contingencies, resource management, early notifications of possible delays, and in the worst case,
alternative temporary residences for the people involved.


Open source projects and small projects really don't need anything more than spreadsheets to manage their projects and proper management of resource. Joel has a good article on spreadsheet management of projects: http://www.joelonsoftware.com/articles/fog0000000245.html

Intestingly enough, he's moved away from the spreadsheet approach, and moved to a more corporate approach: http://www.joelonsoftware.com/items/2007/10/26.html

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 192.75.165.28] on February 27, 2008 06:32 PM
My anonymous, you have some bad experience with bad project managers, so let me clarify what I meant.

Linus is a good project manager *now* because he set up a release system where he can deliver results regularly without too much management or thought.
He was a bad one in the 2.2 and 2.4 days because the early versions were notoriously buggy because he wasn't able to control either scope or quality or time.
Getting back to your "work harder!" comment. That's call a "death march" (see http://www.informit.com/articles/article.aspx?p=169512 ) and a good project manager would never get into that situation, if it he does, it's his own fault and should be held to account on this -- no excuse.

The key job of a good project manager is to say "no, what you're asking is impossible" if it is impossible (which Linus is very good at doing now but not before)
to their managers, their customers, and even the people who do the work (especially if they think they can do the job when all indications say
they can't). The key thing involved isn't being technical or being an administrator but being realistic and getting everyone involved to be realistic. Nothing more and nothing less.

The good project manager has to be the bad guy that everyone loves and respects in the end (which Linus is -- people love him even though
he claims to be a real SOB). A fantastic project manager is one that's able (like Linus) to make his involvement almost transparent so it
looks like he's doing nothing at all but things are delivered on time with the correct features and quality, and when disaster strikes,
there are enough contingency plans in place so that things still get delivered on time and with the correct features without having
everyone run around like chickens without there heads or being tied to the oars of a slave ship.

#

Re: OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 87.211.186.131] on February 27, 2008 07:49 PM
(Wow, do I dislike the lack of formatting in comment posts). You are still missing the point. Nobody mentioned anything about project managers "being technical/administrator". However, it is important for project managers to understand the work that is being done, to some degree, in order to manage the people and their work/deadlines properly. And the second point is that, assuming you're the second anon that replied, you are, as joe barr said, wrongly correlating project management with the ability to work with (new) project management tools. They are different things and it was a rather inappropriate way to tackle the credibility of this review.

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 192.75.165.28] on February 27, 2008 09:06 PM
(I agree about the lack of formatting in comment posts) Mr anonymous, related to Joe's response. I *agree* that project management ability has little to do with the tools you use...look at my comments (if you can make out the formatting). I also agree that this has little bearing on the quality of the review, which I thought was good. Good quality reviews require a lot of work and it's rarely appreciated. My response to you was from specific parts of your response to me "Work harder!....I hope you're not a project manager." which has little bearing on anything I said, so I clarified those specific points. Note *am an not the first anonymous post*. I suspect that's where your confusion lies (I didn't recognize this before this post, so I apologize for not making this explicit....another job of the good project manager - making hidden assumptions and ambiguities explicit). The response previous to that was in response to Joe's question on my opinion on the difference between open source and corporate project management. Hopefully everything is clear now so we can all move on.

#

Re: OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 87.211.186.131] on February 27, 2008 11:47 PM
Hehe, there's something funny about anonymous peeps commenting on anonymous peeps and getting confused. I'm sure there's a good joke in there somewhere. Anyway mr February 27, 2008 09:06 PM. My comment about "work harder, make the deadlines" was just an example of how that is nowhere near the full capabilities of good project managers (obviously, that's an important part, but that still requires "technical" knowledge to some degree). So as far as I can tell, we're on the same line.

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 87.69.67.14] on February 27, 2008 09:10 PM
I also want to point out another great project manager, take a look at taskjuggler (http://www.taskjuggler.org/)

#

OpenProj: good software, but needs documentation

Posted by: Anonymous [ip: 72.226.95.254] on March 12, 2008 12:29 PM
although I have not been using MS Proj lately, I have been using that type of tool starting in the dual floppy PC days! I've spent a few years with MS Proj and have used several others on both PC's and mainframes.... One of the first times I was using MS Project, I had to teach a colleague how to use it. Unfortunately, the copy we were using was in German (we were in Frankfurt, so that's no surprise) except that I didn't speak German at the time... so I had to muddle through that and MS Project - and we still got things going because I was very familiar with all the terms/structures of project mgmt.

I played with OpenProj earlier and found a few limitations, ones that subsequent releases would probably address - some user interface, mainly printing/output formatting.

I also tried taskjuggler and planner and gave up on those in favor of http://ganttproject.biz/ (Gantt Project) as I needed something to share with my Windows-only friends/clients. Gantt Project is pretty simple to use and is much easier if you have to LEARN about project mgmt while you are also learning the software.

Having said that, OpenProj actually COULD be an MS Proj replacement, even in the business world. But, its no less complicated than MS Proj for a larger project - but also no more complicated than MS Proj would be for a similarly sized project.

So if you already KNOW how to do PERT/GANTT/resource management, head to OpenProj for a test drive. If your project is not very complicated or you are new to all this, then I'd suggest Gantt Project instead.

enjoy! and as we say, YMMV (your mileage may vary)!
Mark

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya