Open Source Scheduling and Project Management Tools

I receive occasional queries for good open source project management and scheduling tools.  As you probably know by now, our scheduling tool of choice for Fedora is TaskJuggler.  TaskJuggler provides a great benefit to Fedora in its flexibility as a reporting tool and is a key driver behind the weekly schedule reminders.

Here is a list (in no particular order) of open source project management tools I’ve come across or have heard suggested by others.  I can’t really attest to any of these being better than others, but hopefully it narrows down an initial Google search.

What others would you add to this list?

Image by mandiberg via flickr used under a Creative Commons license.

Mind Mapping With VUE

While searching for a solution to a problem with XMind, I came across this forum post mentioning VUE. I haven’t spent very much time with VUE, but it appears to be a very robust and full featured mind mapping tool.  It is completely free and open source.  I wonder how many more of these great programs are out there just waiting to be discovered.

VUE appears to take a middle ground between the flexibility of a drawing tool and the core functionality of mind mapping tool.  There are definitely situations where beautiful shapes and connectors are less important than node or text placement or the ability to set the size of a node. VUE could be an advantage here.  VUE also has a presentation mode which looks interesting and is not available in the free version of XMind.

Freeware Genius has a full-featured write-up explaining VUE in detail. Example VUE mind maps are also at the home page gallery.

Problems With Rapid Node Creation Mode

The same key and mouse combination (ALT + Mouse) that plagues Gnome Linux users on XMind also happens with VUE.  Changing the mapping for ALT + Mouse fixes the issue.  See the VUE guide for more information on rapid node creation.  It is a little unique, but after playing with it I liked it.

Running VUE on Fedora

VUE is not packaged for Fedora. To run and install on Fedora:

1) Register for an account–annoying compared to 99% of the other open source projects out there, but in this case it’s worth it.  There are some files on sourceforge, but they appear to be older versions.

2) Download the “Linux / Generic JAR-only version (no installer included)”

3) Unpack the zip file to a directory

$ unzip -d ~/vue-3.0 VUE_3_0.zip

4) Run it

$ java -jar ~/vue-3.0/VUE.jar

Inconsolata: A Great Fixed Width Font

The Fedora Project’s in person events are great for picking up new applications and tips from other people.   I love it when little surprises come along that make the desktop experience more pleasant.  Discovering Terminator was the last time this happened.  At the Fedora Talk FAD, Paul Frields took my terminal window to a higher level by suggesting switching to the Inconsolata font.  It is a very pleasant fixed width font that I’m using just about everywhere now.

$ su -c 'yum install levien-inconsolata-fonts'

It turns out there are several other programming (fixed width) fonts that people love as well.  They are worth checking out if you are looking for some other fixed width font options.

Planning to Slip the Schedule

A discussion recently started on fedora-advisory-board list about the Fedora 11 schedule and turned to how much we have slipped in the past.  Admittedly it is kind of hard to say because we haven’t diligently tracked or reviewed our planned schedules to actual events.

I didn’t start tracking plan to actual data clearly until Fedora 9.  At the time I think some people thought using a scheduling tool was overkill for Fedora.

The farther back we look at our release schedules the less they tell us about how likely we are to slip today.  This is because Fedora has been a constant evolution since it started.  Even as recent as Fedora 7 the release process was undergoing major changes when the famous merge of core and extras happened.  I don’t have any schedule data readily available for that release, but I recall it did slip by at least a few weeks.

Here is what I know from the schedule data I have from recent releases:

  • Fedora 8 slipped overall by approximately one week.  We did not adjust the end of Fedora 9 for it.
  • Fedora 9 slipped two weeks total.  We did not adjust the end of the Fedora 10 for it.
  • So far Fedora 10 has slipped by four weeks.  After the infrastructure incident we slipped by three weeks.  Another week was added when we  missed the beta freeze.

One thing I really dislike about Fedora schedule discussions are comments along the lines of:

We’ve always slipped

This is Fedora

Unexpected things always happen in our releases

We should always assume we will slip

As a release we set our standards pretty high when it comes to things like free software and excluding binary drivers.  Why is it when we talk about our schedule we lower our standards and resign ourselves to slipping even before we start?

I fully understand that we can’t plan for every unexpected emergency, but there are ways to build our schedules so that slips are less likely.  We can also be more aggressive about guarding against them.  I think in the past couple of releases we have constructed better and more predictable schedules.  We are also looking at ways to add more predictability to the Fedora 11 which builds in more protection against slipping–addressing the reason why Fedora 10 slipped by one week freezing for beta.

I don’t think speculation about slipping, and if so, by how much, should be part of trying to figure out the Fedora 11 or Fedora 12 schedule end dates.

Miserable Job

Have you ever had a job you did not like?

This book–described as a page turner by one reviewer–is a fable illustrating what separates good jobs from bad ones. I think it also speaks clearly to the keys for success in any situation where a group of people is trying to accomplish a common goal. The story moves quickly, and while contrived at times, makes Patrick Lencioni’s three main points clear.

Lencioni contends that there are three primary contributors to a miserable job which he describes in the following way:

Anonymity

People cannot be fulfilled in their work if they are not known. All human beings need to be understood in a position of authority…. People who see themselves as invisible, generic, or anonymous cannot love their jobs, no matter what they are doing.

Irrelevance

Everyone needs to know that their job matters, to someone. Anyone. Without seeing a connection between the work and the satisfaction of another person or group of people, an employee simply will not find lasting fulfillment.

Immeasurement

Employees need to be able to gauge their progress and level of contribution for themselves. They cannot be fulfilled in their work if their success depends on the opinions or whims of another person, no matter how benevolent that person may be. Without tangible means of assessing success or failure, motivation eventually deteriorates as people see themselves as unable to control their fate.

Lencioni concedes that immeasurement is not a word in the dictionary sense, yet contends that creating this word is the best way to makes his point.

Thinking back to different jobs I’ve had, it is fairly easy to sort out the winners and losers based on this criteria. In some cases it is clearer now why I was dissatisfied and moved on.

While Lencioni’s target audience is the traditional employeee employer relationship, these same attributes carry over into most forms of satisfying work–including open source projects. Naturally in most cases community members are not paid or employees in the traditional sense.  And if a project is failing in all three areas, most people won’t stick around. The whole notion that open source projects thrive and succeed simply because a bunch of people “got together to scratch a common itch” is too simplistic and not sustainable long term.

Unintentionally, I’ve been thinking a lot about irrelevance and immeausurement as I’ve worked with Jon Stanley to help relaunch the bug triage effort. Who wants to invest time trying to make a dent in 13,000 open bugs if it does not appear that their efforts are relevant? Who wants to triage bugs day after day if there is no way to measure their progress? Who wants to incur the occasional wrath of frustrated bug reporters and package maintainers if no one recognizes their efforts? Long term, even if people feel that their efforts are relevant and showing measurable progress, they will eventually get discouraged if they do not feel their individual efforts are recognized–anonymity.

The punch line here for anyone interested in helping with Fedora bug triage is that we are doing our best to make sure it is is not a miserable job :-)

The concept of immeasurement puts a positive spin on metrics–often the bane of many individual contributor’s existence. Lencioni suggests how miserable basketball players would be if no score was kept and the winning team was selected by a group of subjective judges. Or how miserable a baseball pitcher would be if his performance was judged by the gut level of his coach instead of the statistical results of his performance. As a counter point, Lencioni also suggests that if the people being measured consider the metrics onerous, the wrong things are probably being measured and are not helpful. Naturally, the best measurable items are usually ones that the measuree agrees are relevant and important, and thus buys into.

This is a great book for anyone that does work of any kind. Its target audience is encouraging managers and CEOs to treat their people well and the compounding benefits that can result. Employees can take just as much away. It is also a great read for anyone unhappy in their present job.

Lencioni suggests asking potential new employers how they treat their employees in terms of anonymity, relevance, and measurement during the interview process. If you don’t get a good sense about these three areas the chances of finding a new satisfying job are probably low. This book also helps explain why a job that appears very mundane to you could be very satisfying to someone else.

Another highly recommended by book by Patrick Lencioni is The Five Dysfunctions of a Team. It includes a number of great insights into well functioning teams and how to lead them. It is a short quick read, told in the same fable style as Three Signs of a Miserable Job.