On 11/28/2013 09:42 AM, Joerg Stephan wrote:
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"
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?
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org