Managing open source projects
One of the biggest challenges we face at Osmosoft is figuring out how to manage projects. Might seem like a simple problem to solve, but if we're trying to help BT to understand open source, then what's the point in using traditional (project) management techniques? We already know how to manage these kinds of projects.
Surprising fact: What we (Osmosoft) can learn about open source projects is much more important than the quantity and timing of software that we create. We're interested in the innovation mechanism. The notion of delivering projects 'on time, on budget' doesn't apply in the same way here.
In order to learn about innovation in open source, we ought to individually behave like open source developers. In this case, we would only work on the things that interest us on an individual basis (scratching our own itch). And we wouldn't work to any imposed or superficial deadlines. If teamwork is needed, it will happen without management interference.
This raises some tough questions, which I've had a stab at answering below. These answers are all quite crude, partly for reasons of brevity, but I'm keen to share the learning process in case others have a view they'd like to share.
Q. How do we (Osmosoft) reconcile this open source model with the needs and expectations of a large enterprise?
A. It depends on what the needs are.
If we're talking about something with a tight deadline, then open source mightn't be the right way to go. But is that deadline really necessary? People don't remember when software is late, they remember when it's poor.
If we're talking about a job that needs to meet a pre-defined specification, then again perhaps this open source model isn't the right approach. Telling open source developers what to do is bad enough; telling them how to do it is fatal! One can simply pay a programmer or team to do the job in this case. Releasing it to the open source community afterwards, to benefit from broader scrutiny and improvements made by other developers, remains an option.
So there are optimum projects which lend themselves toward open source, particularly where commodities are concerned.
Q. What if we (Osmosoft) have projects that depend on input from people who aren't interested in taking part?
A. Well, what happens in the open source space? The person who needs it to be done finds a way. It might involve them learning the required skills to do the job themselves. From my perspective, this is getting easier as software becomes more powerful.
But this puts my role as product owner for RippleRap in a precarious position. I can't code, so I'll be relying on the goodwill of the TiddlyWiki community to move things forward. This might involve my colleagues, and then again it might not. But if this was a commercial product, I'd be inclined to default to more traditional processes (paying someone to do the job). And in fact if I had to go down this path, I'd be questioning whether further RippleRap development is really the best use of my time here at Osmosoft. Such is the nature of open source projects.
Q. One analogy made regarding open source projects is that it's like living in a shared house, where everyone wants to choose the wallpaper (do the fun jobs) but no-one wants to clean the toilet. How do we make sure that the un-fun jobs still get done?
A. Again, what happens in the open source space? Usually, someone in the group is compelled to get this done. It takes a special kind of person to do this. But if this person didn't exist, then one answer is trying to make these jobs more fun. We're organising a hack day of sorts to try and achieve this, where some of our guys are joining together (voluntarily) to work through some of the bugs in the TiddlyWiki core. Good experience for all concerned.
Q. If we try and remove salary and management pressure from the picture, what other motivational forces are at play? Just scratching your own itch, or something more?
A. This is a big one! Many others have tried to answer this question. Peer pressure and pride are, I suppose, the obvious ones. Not to mention the architectural purity that developers often pursue (partly down to pride, of course). I want to get better at understanding this - watch this space.
And my own personal favorite.....
Q. What is the role of a project manager in all this?
A. I'm not a project manager! Not any more anyway. But I do come from this background, and I can't help but use it as my frame of reference. I think there's still a role for someone in an open source project to coordinate efforts, especially when the project is above a certain size, and possibly alongside a benevolent dictator that is the hallmark of many successful open source projects. I'm finding it fascinating to consider this role in contrast to the old role; I believe that many of the skills are transferable, especially diplomacy skills! A subject for a future post.
++
In reality, I think we'll still occasionally have to do things that we don't want to do. For example when people in BT need help with TiddlyWiki. But as far as practical we'll be pushing the above agenda and I'll keep you posted on the things we learn.
This was a challenging post to write. I'd welcome any feedback, no matter how critical.
++
UPDATE: Later that day....so I've been urged to reconsider whether we're doing open source a disservice by assuming all open source projects and communities are like TiddlyWiki. And also by assuming that all open source developers are 'scratch your own itch' kind of guys. So perhaps we should say for now that we should act like beekeepers (analogy stolen from psd), and aim to develop an environment in Osmosoft where people assume the roles that they feel comfortable in, to most closely match an open source environment.
Surprising fact: What we (Osmosoft) can learn about open source projects is much more important than the quantity and timing of software that we create. We're interested in the innovation mechanism. The notion of delivering projects 'on time, on budget' doesn't apply in the same way here.
In order to learn about innovation in open source, we ought to individually behave like open source developers. In this case, we would only work on the things that interest us on an individual basis (scratching our own itch). And we wouldn't work to any imposed or superficial deadlines. If teamwork is needed, it will happen without management interference.
This raises some tough questions, which I've had a stab at answering below. These answers are all quite crude, partly for reasons of brevity, but I'm keen to share the learning process in case others have a view they'd like to share.
Q. How do we (Osmosoft) reconcile this open source model with the needs and expectations of a large enterprise?
A. It depends on what the needs are.
If we're talking about something with a tight deadline, then open source mightn't be the right way to go. But is that deadline really necessary? People don't remember when software is late, they remember when it's poor.
If we're talking about a job that needs to meet a pre-defined specification, then again perhaps this open source model isn't the right approach. Telling open source developers what to do is bad enough; telling them how to do it is fatal! One can simply pay a programmer or team to do the job in this case. Releasing it to the open source community afterwards, to benefit from broader scrutiny and improvements made by other developers, remains an option.
So there are optimum projects which lend themselves toward open source, particularly where commodities are concerned.
Q. What if we (Osmosoft) have projects that depend on input from people who aren't interested in taking part?
A. Well, what happens in the open source space? The person who needs it to be done finds a way. It might involve them learning the required skills to do the job themselves. From my perspective, this is getting easier as software becomes more powerful.
But this puts my role as product owner for RippleRap in a precarious position. I can't code, so I'll be relying on the goodwill of the TiddlyWiki community to move things forward. This might involve my colleagues, and then again it might not. But if this was a commercial product, I'd be inclined to default to more traditional processes (paying someone to do the job). And in fact if I had to go down this path, I'd be questioning whether further RippleRap development is really the best use of my time here at Osmosoft. Such is the nature of open source projects.
Q. One analogy made regarding open source projects is that it's like living in a shared house, where everyone wants to choose the wallpaper (do the fun jobs) but no-one wants to clean the toilet. How do we make sure that the un-fun jobs still get done?
A. Again, what happens in the open source space? Usually, someone in the group is compelled to get this done. It takes a special kind of person to do this. But if this person didn't exist, then one answer is trying to make these jobs more fun. We're organising a hack day of sorts to try and achieve this, where some of our guys are joining together (voluntarily) to work through some of the bugs in the TiddlyWiki core. Good experience for all concerned.
Q. If we try and remove salary and management pressure from the picture, what other motivational forces are at play? Just scratching your own itch, or something more?
A. This is a big one! Many others have tried to answer this question. Peer pressure and pride are, I suppose, the obvious ones. Not to mention the architectural purity that developers often pursue (partly down to pride, of course). I want to get better at understanding this - watch this space.
And my own personal favorite.....
Q. What is the role of a project manager in all this?
A. I'm not a project manager! Not any more anyway. But I do come from this background, and I can't help but use it as my frame of reference. I think there's still a role for someone in an open source project to coordinate efforts, especially when the project is above a certain size, and possibly alongside a benevolent dictator that is the hallmark of many successful open source projects. I'm finding it fascinating to consider this role in contrast to the old role; I believe that many of the skills are transferable, especially diplomacy skills! A subject for a future post.
++
In reality, I think we'll still occasionally have to do things that we don't want to do. For example when people in BT need help with TiddlyWiki. But as far as practical we'll be pushing the above agenda and I'll keep you posted on the things we learn.
This was a challenging post to write. I'd welcome any feedback, no matter how critical.
++
UPDATE: Later that day....so I've been urged to reconsider whether we're doing open source a disservice by assuming all open source projects and communities are like TiddlyWiki. And also by assuming that all open source developers are 'scratch your own itch' kind of guys. So perhaps we should say for now that we should act like beekeepers (analogy stolen from psd), and aim to develop an environment in Osmosoft where people assume the roles that they feel comfortable in, to most closely match an open source environment.
Comments
I think there's still a lot left for us to figure out in terms of assessing the potential as well as the limitations of the open-source model.
But then, that's what we're here for - and I think we're on a good path.
The OSS itch-scratchers don't see scratching "only" their own itch as a "problem" - often it's an itch that others have too...
Seems simple and obvious, but it's often overlooked.