I (heart) open source. Deeply. There are at least a few dozen libraries that I couldn’t live without anymore. Tons of indispensable products like MySQL, Apache, Tomcat are part of my standard toolkit. But the community hubris that goes along with it…Fuggetabouddit. A recent quote by Django guru Jacob Kaplan-Moss concerning the balance of complex projects, features, release schedules and project management (collectively referred to in the quote as “these issues”) got my hackles up (full read here if you like):
“Open source cleanly avoids these issues by letting technical voices have the last say.”
Really? So developers are now the President AND Congress? We write AND approve the laws?
Unfortunately, I think Jacob has missed the forest for the trees in this case. From a broader perspective, the larger software product ecosystem looks like this:
Customers <-> Marketing <-> Engineers
We have Customers who have a need. Marketing determines their desires, figures out features they want and asks the Engineers to build the product for the Customer. (Obligatory Office Space joke) Customer gets something that is Useful. Everyone is happy.
In Open Source things are a bit different–we leave out the middlemen because we’re building tools and frameworks mostly. We change the Customers a bit because Joe Six Pack, Joe Biden or your Grandma sure-as-heck aren’t going to be putting Django on their machines anytime soon and we get:
Engineers <-> Engineers
Open source sure has something easier to deal with than the earlier picture. And no WONDER the developers get the final veto…chances are, they’re CUSTOMERS. It’s great the Django has the luxury of saying to their developers, “Well, we’re not going to add in the toolbar to the next release” because in reality, that’s not a major loss to their customers. They’re smart enough to find it on their own. They are used to cobbling together things to get their end product working. They’re highly technical and like to tinker. They’re innovators and early adopters in Geoffery Moore’s terms. They understand PC Load Letter (NSFW) on their printers. But they’re the easiest groups to deal with when you’re a technical person. It’s the other groups that are hard–and they’re the ones that make up a real product.
There’s a distinct difference between a project and product. Project managers (like Jacob on Django) are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager will work to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. Product managers, on the other hand, are responsible for the overall and ongoing success of a product. Once the project to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire lifecycle. These two roles are often at odds with each other, but it’s clear that Django doesn’t need or have a product manager because Django doesn’t fit into the category of a mainstream product. It won’t be sold or marketed like Photoshop or Excel. You won’t have customers that nicely follow Moore’s technology adoption curve.
Feature set balancing for real products and serious projects requires more than just a bunch of architects sitting in an ivory tower with a REJECTED stamp and red ink pad. There are revenue considerations to be made, customers that would buy your product because you now have feature X, and competitive analysis to determine market viability. None of which has anything to do with the purity of the code base, what your UML diagrams look like or how clean you keep SVN.
Sorry Jacob. That may work for Django but you might want to look at some broader, successfully released products before pounding your chest about the reason for your wild success on a project.