Tuesday, February 5, 2008

Plone-the-product vs. Plone-the-platform, Joel-on-software edition This week Plone has a summit to discuss strategy. For me, "strategy" means high-level kinds of questions like: - What should Plone do well (vs. not worry about doing well) - Who is it for (vs. not necessarily for) - What makes it unique (vs. what things are commodity) - Who are your natural competitors Using summit time to assess features for future releases is a good idea. But there should also be time to tackle strategy decisions that inform feature planning. I believe Jon is helping make that happen. In trying to help sort out such strategy questions, it's useful to make a distinction between "Plone-the-product" and "Plone-the-platform" (aka the framework). The former is an out-of-the-box application with specific functionality for certain users. That is, a specific user experience. The latter is UI-less set of capabilities from which you can go in various directions to make your own products. And each has a totally different set of answers to the questions above. Stated differently, a totally different "strategy". In trying to bring this up, I get either strong support or strong pushback. The latter goes along the line of "we're both", "why limit ourselves", and foremost, "why does it matter". In this case, Joel Spolsky does a very admirable job discussing platforms. It's really, really important to figure out if your product is a platform or not, because platforms need to be marketed in a very different way to be successful. That's because a platform needs to appeal to developers first and foremost, not end users. I just had the good fortune to read an advance copy of Rick Chapman's excellent new book on stupidity in the software industry...One of the biggest themes in software industry failures is a platform vendor that didn't understand that they were a platform vendor, so they alienated their key constituency: the developers. Over the course of Zope's history, I've watched this issue go through several permutations. The original Zope was a product that tried to hide, of all things, Python. It then grew an extension concept (Products) for developers. The extension part was so popular that Python developers became the core constituency. Zope 3 mostly-abandoned the "product" side, while still sorta implying it would come up with backwards-compatibility to keep those interests in the fold. Instead, Zope 3 was a self-contained application server and platform. And now, having failed to get traction as a self-contained universe, there is a final push to make it assume its most natural place as a system of awesome, high-quality Python components. (See Jens's response on "The Zope Confusion".) I also think Mozilla is an example of not knowing if you're a product or a tool. Three years ago, Mozilla was trying to make the best browser on the planet. Oh, and a great mail client. And a great calendar. And (of all freaking things) chat client. Oh, and it was also a platform of technologies (XUL, etc.) to write extensions for said suite of stuff that went along with said browser. In fact, forget our products entirely...Mozilla is a platform for building *anything*. People got woefully confused. What exactly was Mozilla trying to succeed at? And so Mozilla re-branded: the browser became Firefox, the suite was sent to Siberia, the mail client was spun out, and the chat client was "set free". The word "Mozilla" meant platform. And that still wasn't enough focus. The Mozilla Foundation finally, FINALLY made it clear whether their raison d'etre was to make a killer browser or a generic internet technology. They say that in the ham-and-egg breakfast, the chicken is interested but the pig is committed. MoFoCo said the browser *would* be excellent and the plaform *should* be excellent. Big distinction. Using the word "Plone" to mean both the product and the platform is, IMO, the least attractive way forward. It will never be clear to people what, exactly, Plone is and isn't for. What is it committed to excellence on. Who is its primary audience. And finally, the reason for not choosing product-or-platform will become the ultimate "house divided against itself" outcome: people will think Plone components developed for the Plone framework will only run in Plone. The good news is that Plone already runs on a framework. In fact, several frameworks (Zope 2, CMF, Archetypes, Zope 3.) Anoint one (or help invent one) as that which people should pay attention to, then invest our activities under that flag, and make Plone a gorgeous assembly atop that other framework's genius. 3:10:18 PM   comment []