I would like to address a few things in this post. First of all, why a strategy, and what will it and won't it do? Second, there is one strategy I'd like to mention specifically, as I think it's disrupting but as a community proposal it deserves to be discussed as any other strategy. That's about the KDE strategy for openSUSE.
But first about the idea of a strategy in the first place. The strategy portal page talks about it plenty and I won't repeat that. I only want to stress what a strategy does and doesn't do.
- help make project wide decisions; for example say we choose the home for developers proposal and the liveCD is full. Do we remove the second media player or the second debug tool? The first it is...
- help focus marketing; say the marketing/promo team wants to set up a campaign targeting a group of ppl, who should they choose? A clear focus helps a lot.
- help attract contributors; having a clear story and purpose helps attract contributors. It will also attract a specific kind of contributors, to be precise the ones to whom the strategy appeals and who are thus likely to implement it.
- help in making a choice; if you're a contributor or user you have certain needs. Looking at the strategy and marketing can help you make a decision for one or another distribution!
Note that all these serve to make the impact of the strategy bigger over time - people who like it will start using it, voice their opinion, get involved, steer...
It does not:
- mean we become less open; so if you want to focus on creating a pro-audio spin while the community has chosen for the focus on developers - go ahead. Nothing will change in that department: who codes, decides, and we're an open community.
- mean we will actively remove things which don't fit the strategy; so if we focus on being being a mobile and cloud distribution, we won't remove OpenOffice for Google docs! We might put a Google Docs button in the menu, next to OO.o, or we might put resources in google docs import/export instead of MS Office 12 support.
So a strategy gives focus and direction, but does not limit much - except when it comes to either-or questions where it gives direction. A strategy is also broad - it has influence on pretty much everything you do. Example: server technology. The cloud proposal has influence on openSUSE as a server - we would integrate and ship things like OwnCloud, Etherpad and similar server technologies in an early stage. As a base for deriviatives we would make sure setting up a server can be done easily from the SUSE Studio GUI. And when we aim for developers, the build service should be integrated so developers can write their application and build it for over 10 distributions with one click.
And third, besides giving focus and being broadly applicable, a strategy also unites. It gives everyone in the community a common goal, lets us focus on our strengths, and binds us.
the KDE proposalLooking at those three goals of a strategy you might understand a bit better why the number 1 KDE strategy ain't the best of the proposals. While you all know me as a KDE guy, I can't really support this idea. Talking to the strategy team and the dude who submitted it initially (Marcus), it has been improved a bit. It used to just talk about KDE - as in, let's be Ubuntu for KDE. That is focusing on a solution, not stating the goal or the problem you try to solve. Now it proposes to have a strong end-user focus, making it a bit more inclusive. You can then choose the right technology for the right job.
Still, while the strategy focuses on a traditional strength of openSUSE (a great integration of KDE apps and a good Plasma Desktop setup), it does not bind but it segregates.that is another traditional strength of openSUSE: being a broad, all encompassing community. This strategy is not broad at all (it is still only about one desktop technology) and does thus not give direction for a large part of the openSUSE community. Moreover, it's too specific and technical to attract most 'common' users. They aren't interested in technology but in the result.
I think it might be good for KDE and in the long run might work for openSUSE. Even though focusing on technology instead of the goal (end users) Not so sure about Free Software in general however. We, as in the Free Software desktop community, were just starting to build real bridges between each other - next year will have a Desktop Summit again!
Perhaps more important, this proposal would chase away an important part of our community - the many non-KDE users and contributors. And the costs could be serious and in many area's. KDE and Gnome technologies can help each other. A good example of that, something I've been lately involved in (yet I needed Bryan to remind me of it) would be a11y or accessibility. This is something which has been moving within the KDE community lately, in part due to some inquiries a government organisation did at last Linuxtag. However, there currently are very few good tools like screen readers written on KDE technology, to eg the Orca screenreader has to be used. Which is fine - and something openSUSE has an edge in as we ship both good KDE and Gnome libs and apps!
What it should be
I think it would be good to have a proposal focusing on end user products, on something aunt Tilly can work with. openSUSE could be a distribution aiming for polish, the final touch. Working on creating a great end user product. And both the Gnome and KDE people would be able to work with it, as would the Apache team, the Kernel team and all others in the community!
I'd be willing to write such a proposal (yes, short notice, I know) if ppl think we should have it. I'm NOT saying here that that's the direction we, as in openSUSE, should choose - personally I like the poweruser proposal as well as the developer proposal. Oh and the cloudy one as well... Besides, I've been involved only so short, my vote doesn't count as I'm not even an openSUSE Member right now. So the openSUSE community should vote - not me. I'm just here to help!