On 11/28/2013 09:42 AM, Joerg Stephan wrote:
Hi folks,
Agreed. But there is a big and growing gap of missed opportunity between what openSUSE does and the way SLES is positioned and is used. Things that would make openSUSE more relevant to users and a more attractive investment target for SUSE.
I agree here with almost all your suggestions, with one caveat. Do not try and position openSUSE as a demo platform for ISVs. Don't get me wrong, I strongly believe we need to get more of the open source based ISVs to support openSUSE, but we should not switch the focus of the distro to support that goal. Having openSUSE as the premier platform for software development should be the goal.
To reach the goal to be a platform for something we really need to discuss the lifecycle of our distribution.
Isn't that where this whole thing is leading? I bet in the follow on e-mails, which I have not yet had the chance to catch up on, the ulterior motives of the statistics collection will reveal themselves. As Klaas mentioned, numbers are generally collected for a few reasons - pat yourself on the back - try and understand some undesired symptoms/results in the present based on past stats - bring about a change thinly veiled in statistics with a "negative" trend.
When i talk to developers, they dont want to switch to newer upstream versions every 18 months. No application lifecycle can handle this.
But the question here is, are applications that we do not build in OBS part of our target? If those applications are open source, they possibly should be part of our target, then why are they not in OBS? What does it take to get those companies/developers to build their application in OBS? Once open source applications build in OBS the life cycle discussion goes away, for developers; and to a certain degree for users as well. For developers the app is build in OBS and is always integrated with the "latest and greatest", thus handling change, which is incremental but frequent becomes a small effort compared to handling the accumulated set of changes at every release. For users the life cycle becomes somewhat immaterial as the application has already been tested on the release as it was part of the development process. When it comes to proprietary applications I am not certain we should care. I do plenty of that w.r.t. my $DAYJOB and let me tell you, it's not pretty and no life cycle is slow enough for proprietary app developers not even the SLES life cycle of almost no changes for eternity.
A good example would be to have Spacewalk packaged and available for openSUSE, it is after all the upstream project for SUSE Manager. SUSE can get some useful feedback on core functions from the community, and then further tailor the value add component on top.
We should not forget the tools we already have. We have WebYaST and AutoYaST. we just need to combine the features and share them via an central webinterface. Such a solution is only attractive for companys. No homer user would use a toll like this, but openSUSE is far away from being a solution for any company (lifecycle, server version, etc)
Well, that is a bit too generic for my taste. openSUSE is not a solution for a company that needs proprietary applications. But than again neither is almost any other community distribution. One of the key ingredients here is commercial software support. Most companies will rely on some sort of proprietary applications and those generally do not support community distributions. For companies that do without proprietary apps or are willing to put up with a mixed environment I do not see the life cycle as a disadvantage. No one forces anyone to upgrade. Ubuntu LTS, that has been mentioned as an example, has a 24 month life cycle, we have 18, or 36 with Evergreen, thus I'd say we have the time frame covered and I refuse to believe that 2 years is some magic sweet spot that makes things work. I think the 2 year period is a number that was pulled out of somebodies.....
I really like this upcomming discussion. Only sad point is that it always comes up on board election and steps back after that. We should never forget that we have a great distribution and we should learn how we can focus on our main goals. Maybe the biggest point is to identify these main goals. For me as an administrator, there are several things i would like to see on opensuse, like a longer lifecycle and a server variant, or especially a team who works on this topic.
With the life cycle you might have a problem as that has a very wide ranging effect. However, if you'd like to see an openSUSE-server "distro" subset, there is nothing in your way to start the effort and get working on it today. The tools are there. This is nothing that can/will.should be decided by discussions or some "magic power group". Having a server profile or subset is a matter of someone doing the work and pushing it into factory and having a team of contributors from around the effort. Be free, go and do the work.
So somebody should make a list with main goals and maybe the community should vote on this.
Well, this is one of my problems, who is somebody? While I agree with Stephan, to a certain extend, that our strategy discussion was somewhat of a disaster, we did emerge with a document. This does describe the things a large part of the community agreed upon as our goals. I do not see where yet another list of goals created by the mystical "somebody" will make any difference.
This discussion goes between 10 people (maximum) on the project list,
Are you suggesting that we have a technical steering committee? Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei@suse.com rschweik@ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org