Browsing Tag

Pidgin

The Failures and Successes of Open Source Product Management

AntI kicked over a small ant hill last week with my post about the (lack of) Product Management being a fatal flaw to open source software. Both CNet and Linux Today chimed in, and that story incited some really good comments. Some of the commentators were gracious enough to continue their dialogs with me in more depth over email. It’s only fair that I follow on that post with some of the great points they made.

First, there was some confusion between Product Management and Project Management. Product Management is still poorly understood and inconsistently implemented in technology companies, so it’s understandable that lots of open source programmers may never have worked with a good Product Manager. Here’s an email exchange I had with a commentator (who asked to remain anonymous):

Paul: …maybe we’re talking past each other on the definition of project management vs. product management…

Anonymous: …I use them nearly interchangeably since all products result from projects. The problem I have in your posting is your blanket implication that development style makes FOSS management inferior….

…I disagree strongly that project and product mgmt are interchangeable terms. Product management is the discipline of discovering, documenting, and prioritizing user problems, it looks at the market strategically and seeks to understand where the greatest user pain is and (in commercial companies) which problems can be solved with the most profit. Project management is tactical scheduling, resource allocation, etc…

This leads to Point #1: The “Product Management Probem” is not unique or limited to open source projects. This is completely valid. You can easily point at Microsoft or other commercial software companies for examples of products that had poor product management and don’t necessarily solve a pressing need. The Pidgin example happens to offer a teaching opportunity in the FOSS world, showing that no person or model is perfect.

Point #2: Many commenter’s stated (paraphrased): “We don’t need Product Management, that’s for commercial companies; free software already has a method to determine wants and needs across groups of users – it’s called forking!”

Forking is when a developer decides to branch off of a project to create something different, usually withing the same vein and built on top of the work that has occurred to-date. In fact, there is already a fork of Pidgin called Funpidgin that exists just to give users back the features that the Pidgin team “took away.” I would say that forking is a very inefficient way to solve this problem, but a commenter smartly called me out on that point saying that unlike in commercial companies, open source projects are not resource-bound – they can afford to be inefficient.

The main point of the post, beyond even the Product Management topics, is that a FOSS 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 since you’re building an application for yourself. 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 open source software 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.

What if when you went to to SourceForge, you saw a badge affixed to the link that told you if this was a for-developers or for-users download?

Who are we creating for?

At least if you understood this bit of information at download time, as a user you wouldn’t bother going to offer feedback to a team that isn’t interested.

Point #3: “FOSS projects air their dirty laundry for the World to see, whereas commercial products get to keep it inside their four walls.”

Yes and no. Yes, open source is out there for everyone to see. Don’t think for a second that just because a product is commercial that the tradeoff decisions those teams make don’t spill onto the Internet. Just look at Microsoft Vista for an example. Or Facebook’s advertising platform.

Point #4: “There is Product Management in open source today! See JBoss, Mozilla, and others!”

This is an important point that I’d like to recognize. There are companies and projects that are contributing PM to FOSS projects.

I’d like to thank everyone who participated in the discussion!

Why Product Management is Open Source’s Fatal Flaw

GNUFree Open Source Software (FOSS) is great – I have released code under the GPL, LGPL, and similar licenses. There are mountains of FOSS available right now for download from sites like SourceForge and others that save businesses millions of dollars. More importantly, open source software 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, like text editors such as VI and Linux. Most FOSS projects aren’t under the stewardship of a commercial entity (although some of the most successful ones are, such as RedHat, Firefox, and OpenOffice), they are built by and for a handful of developers “scratching an itch,” and they are not working with a Product Manager. Unfortunately, FOSS 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.

Continue Reading