The Over-bearing and Intellectually Stunted Managers of FOSS


The title was bait; I do not feel bad admitting it. There are no over-bearing and intellectually stunted managers of free and open source software projects. However, I want to point out that this is one of the most appealing aspects of FOSS participation. The people who are working on these projects are often working on them of their own volition. And I’m postulating that those lucky few who get paid to participate in the development and maintenance of open source software a) work in organizations that tend to avoid micro-management and impractical timelines/release dates; and b) are self-motivated, so they tend to push themselves more effectively than any manager could.

A problem with this blissful state of affairs in FOSS management (or lack therof…), is that I simply can not be bothered to stay on task with open source projects. Since I am making an effort to Get Started In Open Source, I wanted to relay this conundrum and offer a few potential solutions I am throwing at it.

First, I want to highlight that I think that I am capable of staying organized, focused, and motivated. Not to mention the fact that in short spurts, I can focus. And I mean focus. I need to figure out how to reliably tap into that capability. To point out an instance of why I think I have this capability: when I got my hands on a 5x5x5 Rubik’s Cube for the first time, I spent most of a day working out the patterns and understanding how the moves corresponded to the 3x3x3. I am dubbing this state ‘cubed’, as in “I was cubed out of my mind.” Or maybe, “I was cubed inside my mind,” probably the latter. While this amount of time is far from ground-breaking on the Rubik’s Cube circuit (the moves among the 3 and 5-sided cubes are quite comparable), I think it highlights my ability to focus my attention. Another highlight of my focus is demonstrated by the fact that I also neglected to eat for the duration of that day.

I relay this anecdote because I want to know not only how I can access this capability to help stay on task, but also how I can get ‘cubed’ on a particular free and open source software project repeatedly. Going back to my title, a manager certainly can not accomplish a ‘cubing’, at least not for me. In reality, I think ‘cubing’ is more about tricking yourself than managing yourself. Drugs manage to trick your brain by degrading body functionalities such that your brain is duped into believing falsities. Even the most ‘harmless’ of drugs accomplish this: pain reliever does not ‘relieve’ pain or make it disappear, it simply tricks your brain into thinking the pain is not there. So, how do I accomplish such slight of hand in the context of open source project participation?

My primary angle lies in generating the puzzle. I love puzzles (Rubik’s Cube, remember). I even love abstract puzzles, like quality assurance. In quality assurance, the puzzle is: can you find the bug? As a matter of fact, I can; and I will not be stopping until I do. ToDo lists, task managers, timelines, reminders; none of these work for me (but these are worth trying, if you have not yet ruled them out!). But if someone indicates that software works, or that a bug can not be reproduced, or that software can not be installed on system x: my brain shifts into overdrive. Those types of blanket statements need to be exhaustively proved, and most people fail to do that before making their claims.

Following this thought experiment, I am giving up on spending (rather, trying to spend) one hour a day, five hours on Fridays, or using any other schedule of events to designate my open source participation. From now on, about once a week, the only scheduled event is the challenge. My primary candidate for challenge day is Wednesday. Wednesday allows some weekday activity and general brooding over the challenge at hand. This also provides the opportunity to do research during the week, which is important because some projects are maintained during the work week, so getting help on mailing lists and IRC can be difficult on the weekend.

Here are some other thoughts I have regarding challenges, note that some of these cater specifically to my goals:

  • Challenges need not be difficult, just perplex enough to be motivating.
  • Challenges must be dependent upon my skill set. This should be obvious, but I want to avoid the temptation of simple challenges. If I am familiar with svn, installing svn and downloading a project’s source is not a challenge. However, if I am not familiar with svn, this may be a perfectly reasonable way to challenge myself for an afternoon.
  • Diversity is important in challenges. The point of the challenge (for me) is not build a little tower of skill in one area, but to genuinely expand my knowledge and skill set.
  • A challenge need not expire in one week. While some challenges will certainly be expunged by the week’s activities, some may live on to plague your efforts for a multi-week period. Others may extend indefinitely (Something like: Participate meaningfully in the project X forums/mailing list).

I am not going to follow a strict challenge schedule (since I already announced that schedules generally fail for me). However, my goal is to pose a challenge on Wednesdays, and I will aim abstractly for 3 Wednesdays a month. I doubt that this technique will work for everyone, and for many a simple todo list or task manager is more than sufficient to keep them on task. Some may read this and assume that I should just give up, because it should be easy to stay focused, and if it is not easy, you should spend your time working on other things. Nonetheless, I resolved to do more in open source in 2011, and part of that resolution was to document the process for the benefit of others. So, I am admitting that I hit a hurdle, and attempting to blast that hurdle to smithereens.

Hopefully it is easier for you to stay focused on your efforts. For me, I hope that I can get ‘cubed’ by the challenges that I set forth, and manage to put forth some useful efforts in my glorious haze. I will do my best to post my challenge, a little bit about how/why I think it will be challenging, and some details on how I plan to complete it.

Challenge 20110202: Pull GeoServer source (svn), update docs pertaining to OpenJDK support (see comments here), generate a JIRA issue regarding the update, submit a patch with the updates addressing the JIRA issue.

Disclosures: I used svn regularly for about 3 years, but that was about 3 years ago, and I have been using bzr and git since. The project is Java, with which I am familiar; but the docs use sphinx, with which I am not familiar.

So this is my replacement for the over-bearing and intellectually stunted manager who seems to be missing from FOSS. If that manager were around to hold the whip over me, I doubt I would need to come up with challenges. But then again, open source would lose a lot of its appeal. What keeps you motivated to participate? How can we motivate others?

2011-02-02
1236 words


Tags
opensource teachingopensource