Marketing gurus Jack Trout and Steve Rivkin wrote a book titled "Differentiate or Die". It's a classic in the marketing field and its message has broad applicability. I think it's applicable, and somewhat important, to us.
The basic idea is that you have to have something... some "thing" that makes your (product|service|project|whatever) **different** from the other players.That is, when somebody says "why use this Mr. Coffee coffee pot instead of this Generic Joe coffee pot", the Mr. Coffee people should have something they can say that truly defines what makes their thing different. It might be "we ship a carafe that's nearly unbreakable" or "our better temperature control gives better tasting coffee", or whatever. Likewise, if somebody asks "why should I contribute to (and/or use) Apache OpenOffice instead of LibreOffice (or whatever)" we should have some good answers, or at least *an* answer. Now for some people, there already is an easy answer, and it's about the ALv2 versus the LGPL/MPL. But I posit that for many people, that isn't an important differentiator. So my thought is, we should think hard about, and articulate, a message in terms of what we want AOO to *be* and how that's *different* from other office suites. It could be anything... maybe we want to double down on doing static code analysis, using fuzzing tools, security audits, etc. and pitch that AOO is "the most secure office suite", sort of akin to the way OpenBSD tout security as their key differentiator. Or maybe it should be aesthetics and/or UX? Or maybe best code quality in terms of "fewest crashes". Or maybe it should be performance (which relates to UX, but I digress). Or maybe there's a particular feature, or set of features, that we want to adopt that will help define what we are. Of course this is complicated by our OSS nature given that any competing projects can easily crib whatever we do, so maybe features aren't the best choice as a differentiator. OTOH, maybe there are things we would do that other projects might not be as interested in. Just to use a made up example, maybe there are features we could add to specifically make AOO more useful for doing "business intelligence", or maybe scientific report generation. Who knows, I just made those examples up with no real thought. So anyway, just wanted to seed this discussion and hopefully provoke some serious thinking around this. Let's think hard about what we want to be so that we can easily say "Why develop/use AOO instead of X?" type questions. Cheers, Phil ~~~ This message optimized for indexing by NSA PRISM
