On prioritizing Open Source projects, tasks: First In, First Out
I have been bit less productive with my "extra-curricular" activities
(open source coding, writing blogs) lately. This is mostly due to
intense focus on my paying daytime job, and is part of the natural cycle
of things for me.
But altohugh I have had bit less time and energy to
spend on these tasks, I have had relatively more time to think about
things. It turns out that amount of time I have to think about things
does not quite correlate with amount of time to do things (which is
interesting thing in its own right, but maybe worth a separate blog
entry). More thinking often leads to having more ideas for writing blog
entries; even if writing activity itself is still constrained by time
crunch.
1. FIFO as a priorization mechanism
Anyway: I have realized that a fundamental operating principle that I
have with respect to managing my open source projects -- tasks within
projects, relative focus between projects -- is that of trying to tackle
oldest issues first. Good old First-in-First-out (FIFO) queuing of
things.
Except for high-priority urgent bug fixes, which I generally
fast track (but which fortunately are not very common), I do try to
increase priority of issues that have not been fixed. This is actually
quite different from many task priorization methods (even if it's
well-known algorithm for operating system process priorization), but
which I feel is an important part of maintaining "culture of
excellence", ensuring that qualtity of project output remains high. And
to reduce risk of letting most of your open source projects stagnate to
death.
Thing is: as with fish (and guests, as per Mark Twaine), bugs also smell more longer they stay. Smell of code rot comes from long-standing unresolved issues. It also tends to be the case that it is easier to keep momentum than to get things rolling -- this makes it hard to revive stagnant projects; but possible to keep recently(-enough) worked-on projects chugging along.
Now: it is bit more well understood that teams should at least occasionally go through list of long-standing issues and ideally not only re-visit them but also fix. In for-profit development targets and priorities tend to fluctuate more than with labour-of-love projects that most open source projects still are. This tends to make it less likely that older issues get resolved, as priorities are more driven by who cries loudest, and most recently. Still, most good developers I know are uncomfortable leaving issues unresolved before starting to extend functionality, to build new things.
But I think FIFO principle as driving force for priorization goes beyond increasing priority of old tasks. I think it also should (and does, in my case) drive relative priorities of different projects (or services, systems, libs, frameworks). And this is something I also try to do more.
2. Example case: my own project priorization ("product backlog")
Specific case in point is that of my focus on my current "flagship"
project, Jackson JSON processor.
Jackson has had my main focus for well over a year now -- mostly since
it is by far the most popular of things I have built; and will likely
remain so for a while now. So if I chose to, I could spend all my time
and then some just working on issues related to Jackson.
Doing so
would, however, essentially kill other projects I am heavily involved
with -- Woodstox, StaxMate, Aalto, Java Uuid Generator -- as well as
prevent me from expanding to new areas (like upcoming "compact trie"
package, google for "ning tr13"; more on this once it is ready to be
announced). And that is not something I find compelling as an idea.
Especially since code that is not worked on will start to rot at fast
rate, and becomes useless surprisingly fast.
So: as frustrating it is to watch issues stack for important projects like Jackson, the way I try to do things is to cycle through projects that I consider worth keeping alive. Sometimes it just means flipping between two projects; and some projects may even become complete in their own right, meaning there just isn't that much to work on, and thus the cost of switching focus for some minor work just isn't worth it. But to give further example of what I mean, here is my current thinking of roughly how I hope to complete next tasks, with respect to projects I work on (note: priorities are not absolute or carved in stone; they are akin to Scrum sprint plan, if even that solid):
- Complete Java Uuid Generator rewrite to version 3.0
- Work on Woodstox 4.1, focusing on XML Schema handling improvements (working with couple of other OS developers who have stake in this area -- including work on Sun Multi-Schema Validator)
- Finish version 1.0 for the "compact trie" project
- Implement minor extensions for StaxMate, to get to version 2.1
- Jackson version 1.6: must have better Enum type handling; should have "materialized interfaces"; can not be delayed too long since there's always version 1.7 to write...
- Compact binary format alternative for JSON (with Jackson as reference implementation)
- ... maybe consider implementing "DataMate" (if you haven't heard my brainstorming on what it is, consider yourself lucky :) )
- Cycle through projects again!
So why consider work on JUG as the first priority? Well, for one, time is right to both upgrade it to be useful and relevant -- there are things like JDK 1.4 - introduced java.util.Uuid class; JDK-1.6 introduced access to Etherner Mac address; as well as "new" use cases (Cassandra, for example, uses Time-based UUIDs heavily!). And as importantly, work has reasonably limited scope: it will take about week more of focus to get it all done; as I have already spend some time over past month or so to make this reality.
And Woodstox? While XML does not have same momentum in J2EE world as it once had, Woodstox is very widely used, complete and useful library. But its XML Schema support has only recently been more heavily exercised, and multiple implementation flaws have been incovered. To make Woodstox relevant as a first-class Java XML Schema supporting tool, some work is needed. Further, there are some useful improvements in trunk that can only be released with version 4.1 (retro-fitting to 4.0 would be too risky).
I think you get the idea -- maybe not exactly why I feel this order is sensible, but at least see that there are multiple conflicting factors. I guess I know my own working habits well enough to know that "out of sight, out of mind", meaning that longer a project is not being worked on, harder it will be to get back to work on it. And so the best way to keep all the balls in the air is to juggle through them; and do this as a semi-formal process and not rely on user request to trigger such changes (esp. since there are more requests for work than time for it).
