openSUSE Strategy: Home for developers

Hi all!

As we promised earlier[1] starting today we’ll be discussing the first
of strategies: Home for developers[2]. Please try to add your comments
to particular bulletpoints or sentences, so it is easier for us to merge
your suggestions into final form. Happy discussing!

[1] http://news.opensuse.org/2010/06/17/a-strategy-for-the-opensuse-project-proposals-and-discussions/
[2] http://en.opensuse.org/Documents/Strategy/Development

prusnak wrote:
> Hi all!
>
> As we promised earlier[1] starting today we’ll be discussing the first
> of strategies: Home for developers[2]. Please try to add your comments
> to particular bulletpoints or sentences, so it is easier for us to
> merge
> your suggestions into final form. Happy discussing!

is it the intention to pick one of the three as the strategy for the
way forward

1 openSUSE - Home for developers
2 openSUSE - Base for derivatives
3 openSUSE - Mobile and cloud ready distribution

or is the intention to so shape the internals of those there paths
so that all of those can be achieved?

i ask becuase i just a few days ago i read an article in Linux
Journal, June 2010, Issue 194, article title Philosophy and Fancy,
page 56 leads me to believe there is already a great “home for
developers” “A distro put together for a hacker will … have a raft
of coding tools … Slackware is aimed squarely at this demographic.”

and, i think it is pretty easy to agree that Google/Android/Chrome is
already light years ahead on the third strategy…

so, will we let the devs currently and firmly in the drivers seat have
their way (number one) or the new kids (and millions and millons of
potential users) theirs (number three) or are we gonna mash’em all
together and continue to produce a stable, dependable, trustworthy
generic base linux (number two) which our major sponsor can turn into
a commercial desktop AND server AND something to sell to the mobile
hardware makers AND . . .?


DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio

One thing I would like to see, as a volunteer for providing support, is some sort of guidance provided by the developers (and the packagers) to the support volunteers , in providing guidance so that the support volunteers can document the way things are done for basic user support.

I constantly find myself reverse engineering (to a limited extent) what has been done, in order to understand enough to write a wiki, or some sort of guide.

This is true not only for the developers, but also wrt the packagers, who play a key roll in repackaging the developers’ applications, so that regular users can use the package. Sometimes how the application is packaged by a packager, can have an important impact on how the application functions.

Now if the developers/packagers will write all of the wiki/guides, then there is less need for such a guidance/communication to volunteers like me (as the wiki/guide created by the developer/packager provides all the information). … but somehow I think the developers and packagers do not want to write the wiki …

So, the question in my mind, is how do we BETTER go about this ? How do we ensure there is a downstream flow of information, instead of a forced upstream reverse engineering learning (which is what happens now to a certain extent) ?

The intention is to shape the internals of the strategies so we’ll end up with one strategy that most of us want to follow. It might happen that activities from one strategy will appear in another, but we don’t want to create a meld of these 3 strategies.

I fully support oldcpu’s request - whatever strategy is chosen. It should be a basic requirement on any organization that has ambition to grow its community of contributors, and to support its existing user group in that effort, not to mention the project’s wider reputation.

prusnak wrote:

> Please try to add your comments to particular bulletpoints or
> sentences, so it is easier for us to merge your suggestions into
> final form. Happy discussing!

your post in the forum didn’t include the text as did your post to the
mail list, i include it now so forum users can copy and then add/edit
as you suggest:

openSUSE - Home for developers


1.) Statement:

We deliver the most integrated platform for developers (e.g. web
developers, system developers, Qt/GTK developers, Android/MeeGo/WebOS
developers, etc.)

To be the ideal home for developers we deliver all popular open source
IDEs and related tools and the perfect desktops suited for them to
make the development efficient. Additionally we deliver a decent
server platform to allow direct deployment of web applications and
make rapid testing possible. By providing integration with social
networks and collaboration tools, we enable developers to work
flawlessly in a distributed environments and enable the usage of
agile techniques.

2.) Activities:

2.a.) We need to be excellent in the following:

* Out-of-box experience for all popular open source IDEs, integration
and development of related tools (graphical debugger, etc.)
* Provide tools to easily deploy developed software (e.g. server
integration, Build Service, etc.) more tightly coupled to tools
* Provide infrastructure to distribute software (e.g. Build Service,
SUSE Studio)
* Provide desktop environments fitting the needs of developers
* Cooperation with team projects to make openSUSE their
development platform of choice
* Deliver the most up-to-date development libraries to make app
development rock (also allow to keep multiple versions)
* Integrate social networks and collaboration tools
* Collaboration with other Linux distros

2.b.) We will try to do the following effectively:

* Provide GUI administration tools, including WebYaST
* Lobby for open standards
* Market openSUSE at events
* Continue testing and bugfixing in an efficient way

2.c.) As project, we will not focus on the following anymore:

* Applications not related to development (directly or indirectly)




end
--
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC'97 Audio

I can not find a point relative to support. Is it just me having another classic oldcpu oversight ? Or is support to users no longer part of the openSUSE strategy ?

prusnak wrote:
> The intention is to shape the internals of the strategies so we’ll end
> up with one strategy that most of us want to follow. It might happen
> that activities from one strategy will appear in another, but we don’t
> want to create a meld of these 3 strategies.

does your answer mean those three are the only strategies available
for the future of openSUSE, and NONE of those can be modified enough
to have a strategy which leads “the Community” into a future of:

openSUSE - A stable (but exciting), dependable (but modern and forward
looking), predictable (but not boring) and secure (yet accessable)
Linux loved by developers, programmers, contributors
mobile/cloud/home/office users, governments, institutions, back
office/cloud/isp/webstore/etc server administrators and Linux
Enterprise software derivatives makers (Novell) and professional
quality server and mainframe hardware makers/sellers (like HP, IBM,
DELL, CRAY, etc etc etc)

is there not room for something like that?

if not, then i’m in the wrong place…and, good luck with the
soon-to-be niche openSUSE operating system.


DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio

oldcpu wrote:
> I can not find a point relative to support. Is it just me having
> another classic oldcpu oversight ? Or is support to users no longer
> part of the openSUSE strategy ?

it is NOT there, anywhere…from the point of view i can gather users
are all of those who do not contribute, and therefore do not count and
should not be considered…

i can only guess that from these few quotes i gathered from the
strategy discussion on the mail list and are representative of some of
“the Community” leaders:

audience is listening only, contributors are taking part. openSUSE is
no big band (maybe sometimes :)) it’s a project which lives from
contributions not ‘feeding customers’.

That’s why I previously said we need more contributors, no users, no
customers, no leechers and no ‘audience’. Don’t get me wrong. As
mentioned, even if you submit a bug and give feedback, you contribute.

It’s US who makes the project vital.

cite: http://lists.opensuse.org/opensuse-project/2010-06/msg00295.html

We can’t have contributors without users and we can’t have users with
contributors, but I think contributors have to come first, because
they are essential in producing what will attract the user.

cite: http://lists.opensuse.org/opensuse-project/2010-06/msg00283.html

To target - and thus to grow - the users , we need to grow the
contributors. Right now I think the openSUSE project should
concentrate on growing the contributors so that those then grow users…

cite: http://lists.opensuse.org/opensuse-project/2010-06/msg00375.html

of course, the problem with that going in assumption is that the only
folks who should download the install disk the FIRST time should be
those who have already contributed, or screw them when they get a
black screen, or format away daddy’s tax records!


DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio

I suspect maybe the need for support was simply “understood/implicit” and so intuitively obvious to those creating the Strategy that it never occured to them as being needed as a separate entry.

But I believe a separate entry for support may be useful to have one, as by adding it as an appropriate separate entry, it could “drive some activities” which will hopefully help developers and packagers (by ensuring users know enough about their (developer/packagers) applications to provide good feedback), it will hopefully help support staff (by ensuring they understand what packagers/developers are implementing and hence can then support users better) and it will hopefully help users (by ensuring they understand how to install, and use applications).

… but perhaps I have missed this in the wording… There IS a LOT of good stuff there.

I don’t see it covered in the wording of the three strategy documents. I don’t see it adequately covered, if at all, in the wording of the Community Statement where I believe your/our request could be best satisfied. The community statement will form part of the winning strategy.

From the “Home for developers” strategy:

As project, we will not focus on the following anymore

* Applications not related to development (directly or indirectly) 

Most open-source applications are in a constant state of development. Please be more precise regarding this bullet statement. Do you mean that all applications not used within or for a development process will be dropped from the distribution?

For the purposes of this discussion, would multimedia apps (e.g. Amarok and Kaffeine), and would audio workstation apps (e.g. Jack, rosegarden4) be dropped from the distribution or defocused in some other way? Of course any answers could equally apply to key graphics or other general end-user applications.

The things openSUSE scores average on we can ignore. The things that need improvement need improved. The things openSUSE does exceptionally need to be improved.

This is a fairly common approach to being good all-around but having a specialization that sets one apart. It helps prevent a niche-mentality and is vital for generalists.

What about the things the project should be doing, but are not doing? How did you score on those, and what are doing about it?

Am I the only one that thinks this is really working around the issue rather than addressing the issue…

Having trawled through opensuse-project I came to the conclusion quite quickly what this is about is oS needs developers. Now rather than appealing and trying to attract developers from the user community they would rather try to either narrow the focus therefore the work load or appeal to developers.

Both ideas seem wrong one there is certain aspects of oS that make it unattractive for developers(Mono, not the latest, easier systems to keep updated to svn, bad PR still bubbling, not vaniila etc, etc) who are not users already, which actually is fine. Why is it fine? Well the users don’t care for those bits they already accept them so rather than trying to appeal to developers who already don’t use the system appeal to the ones that do…

IMO the biggest problem is the devel clique, I’ve seen this in action myself the reason the forum has nttp is due to clique not majority or even what the users wanted. As Jim puts it far more eloquently (Not meant to be taken out of context but strange to see my words nearly repeated word for word 2 years later.)

  1. the technical audience who prefers web forums (or
    NNTP groups) to e-mail lists, and 2) a non-technical audience that is
    made up of mostly end-users.

This makes for an interesting - and occasionally volatile - combination.

The technical audience tends to apply tact to what is being said to them;
the non-technical audience tends to apply tact to what they say. Mixing
the two can be a challenge (I know I’ve mentioned this idea of a ‘tact
filter’ on the user list in the past - that’s what I’m talking about here

Improve the dev clique and maybe you’ll be able to reach the tech savy on the forums to.

I had a laugh out of that. The biggest problem is the people who develope the operating system and its applications ? :sarcastic:

Maybe I misread that, but I confess in many respects it is contradictory to me. …

IMHO the biggest problem is those who do nothing. :stuck_out_tongue:

Not really glad you had your amusement a distro is nothing without users…

The ideal is to have devs that are users first…

From the strategy document:

As project, we will not focus on the following anymore

  • Applications not related to development (directly or indirectly)

Most open-source applications are in a constant state of development. Please be more precise regarding this bullet statement. Do you mean that all applications not used within or for a development process will be dropped from the distribution?

For the purposes of this discussion, would multimedia apps (e.g. Amarok and Kaffeine), and would audio workstation apps (e.g. Jack, rosegarden4) be dropped from the distribution or defocused in some other way? Of course any answers could equally apply to key graphics or other general end-user applications.

Typically in open source, the dev’s will develop an app to address an “itch”. They often write the app for themselves to use, and if others can benefit, great.

Of course all devs are users themselves. Hence by virtue of them selves writing an application that they themselves can use, they are serving a user (ie themselves). The two aspects (coding for a user = themselves) go together and are virtually inseparable in opensource. That is the way it is.

Now Users who use the devs application, and provide positive feedback to the dev, are helpful and they encourage the dev.

Users who provide no feedback, or who only provide constant negative feedback with no contribution, or negative destructive input are a big problem as they discourage the dev, who just may say FORGET IT.

The vision that a developer for the good of their heart is going to write an application that they themselves will never use, but they just want to do it to help an unthankful and disruptive community where that community NEVER helps and NEVER contributes simply is not realistic.

Linux would crash and burn in that scenario.

No one in their right mind would, for free, write code in that environment. That would be the DEATH of Linux.

To say the devs are the problem is laughable. … THEY are the main thing that keeps Linux alive.

There CAN be a Linux with only DEVS and no users. Its not ideal, its ugly, but it can exist. There can NEVER be a Linux with only users and no DEVs. Think about it !