Q. Most commercial software companies employ product managers to handle the planning and marketing of software products, whereas few open source projects have a product manager. Does lack of product management impact the users of open source?
A. Plenty of open source software (OSS) that can save businesses millions of dollars is available right now for download from sites like SourceForge. More importantly, OSS offers feature sets and mixes that often aren't available in commercial products because the market is too small, commercial companies don't understand it, or the problems aren't profitable enough to solve.
The great promise of open source is that you can have equal or more functionality than commercial software for free, and you have access to the source code if you have the desire, time, and skills to hack it into something new. This model was perfect when developers were writing tools for each other. Most OSS projects aren't under the stewardship of a commercial entity, although some of the most successful ones are, such as RedHat, Firefox, and OpenOffice. Most are built by and for a handful of developers "scratching an itch", who are not working with a product manager. Unfortunately, OSS has become a victim of its own success, and today, open source developers are facing a problem that threatens to turn legions of users against the software they rely on.
Most OSS projects are a meritocracy, meaning that the developers care about developing for themselves and their own problems. If non-contributing users' problems happen to be solved, great. If not, "you have access to the code, feel free to build that feature yourself!" Users understand that free software comes with limitations: there is typically only ad hoc support, updates are only as frequent as the developers care to make them, and bugs may go un-addressed forever. Users realized they were getting something for nothing, and were willing to put up with the lack of polish found in most OSS. However, OSS has become so pervasive, the boundaries in users' minds between OSS and commercial software have blurred.
Many OSS products are nearly indistinguishable to an end user from commercial software. This has changed the expectations of users to think that they are the persona that the developer is writing code for. But are they? Some applications, such as Firefox, have made the leap and are clearly developing for an end user. For an example of an OSS project that hasn't, look no further than Pidgin.
Pidgin is an open source instant messaging (IM) client. Recently, they changed the action of the field where the user types their message from a manually re-sizable window to a fixed size window that auto-re-sizes based on the amount of text typed. This sounds like a minor change, but it triggered a massive user revolt! Why?
First, the Pidgin developers violated the Principle of Least Astonishment. Never take away functionality from the user when they upgrade. Second, the Pidgin developers let "Perfect become the enemy of Good". If you take the time to read through the entire discussion, you see statements from the developers such as (paraphrased):"We want to find one solution that fits the needs of all users; we don't understand/don't agree with the use case that calls for a resizable input window". Third, the developers became more entrenched as the discussion progressed, rationalizing the feedback as a "vocal minority", and recommending that users use other applications for their needs. Finally, the thread devolves into the developers reminding everyone that they do this work on their own time, for their own enjoyment, and by the way, they are closing the bug report and tagging it as "will not fix".
The most interesting reply on the bug report is from Dan Livingston:
"I teach "Collaboration in an Open Source World" at a local college. I have been searching for, and in this ticket have found, a perfect example where communication between open source developers and users fails at multiple, fundamental levels.
Obviously, the motivations of open source developers are varied; some do it for technical enjoyment, others enjoy knowing they are contributing intellectual capital to a better world. The problem is when the motivations of open source developers conflict with the expectations of users.
Consider every wildly successful open source project: the users are enthralled with their ability to perform new activities in ways previously unimagined. Rabid dedication grows, and an evangelical fan base results. Pretty soon, it's obvious why users would not want to go with non-open source software alternatives.
What happens when those same newfound powers are taken away? What happens when the developers impose their personal dogmas upon the project? Even for as small an issue as chat window resizing, a minority (or majority) of users will emphatically express dissent....The initial lure of open source software is that quality software should resoundingly meet the needs of users. As demonstrated up until Pidgin 2.4, the fan base has emphatically been extolling the virtues of Pidgin. But when developers take a feature away, presumably to implement a "better version", and that better version in fact is a step backwards from the functionality previously available, they had better have a damn good reason. Such a reason is lacking here...(many of the statements seen in this ticket), which if executed within a corporate arena, would get developers fired. Developers, make note: you are doing a disservice to the community you claim to represent, and are doing so with false illusions that you are "right" because you have convictions in your justifications."
Later, Professor Livingston dresses down the development team with some well-placed satire, by proposing a fictitious letter ghost written for the Pidgin development team.
Obviously, there is a huge gap between the expectations of the users and the developers. Who normally bridges that gap? Product management. A product manager would raise a flag on the change in functionality and help the engineering team prioritize feature sets based on the needs of the target users. Unfortunately, most OSS projects don't have product managers, written personas, or target users; they have developers working for themselves.
I propose that product management should take a more active role in OSS by teaming with developers to identify the target audience and prioritize the users' needs. If developers can donate their time, there is no reason product managers can't do the same thing. Another solvable issue is one of expectations. Open source projects should adopt a clear tag, license, or other marking indicating if the goal of that project is to "scratch an itch" or service a base of non-contributing users. Indicating the goal of a project up front at download-time (for the user), and at code writing time (for the developer) would set expectations appropriately.
Even on a "serviced" project, users need clear guidelines about what is and isn't acceptable feedback. The discussion above started out as civil, but quickly turned into a shouting match, with each side digging in. At that point, no one could compromise without losing face. An OSS product manager could have diffused the issue early, by involving users in the design (pre-code), and being a neutral party to explain the decision making process and tradeoffs.
The "Product Management Problem" is not unique or limited to OSS. You can easily find examples of commercial products that had poor product management. Pidgin offers a teaching opportunity in the OSS world, showing that no model is perfect.
It is common in the OSS world to hear statements such as "we don't need product management, that's for commercial companies; OSS already has a method to determine needs across groups of users: forking!" Forking is when a developer decides to branch off of a project to create something different, usually within the same vein and built on top of the work that has occurred to-date. A fork of Pidgin called Funpidgin exists to give users back the features that the Pidgin team "took away". On the one hand, forking is an inefficient way to solve this problem. On the other hand, unlike in commercial companies, open source projects are not resource-bound and can afford to be inefficient. An OSS project can have one of two primary goals: either the developers are creating for themselves, or they are creating for others. To create for yourself means that you recognize user input but don't feel any obligation to take it. If the user happens to enjoy it, great. If not, fork and make something you like.
If you're creating for others, you should be interested in the wants and needs of your target user base. This might mean forgoing a "cool" or technically challenging feature like auto-resizing text boxes. Now that OSS looks, feels, and acts like many commercial packages, users assume that the application was developed with their needs in mind. If the application does not meet their needs, they feel justified in offering feedback. This is where the disconnect comes from: users who assume that an application was developed for them and programmers who believe they are building primarily for themselves. If the programmers are interested in working for a larger user base, a strong product manager could help them fill that gap.
For more information on this topic, see the author's blog which includes his initial entries and ensuing discussion.