[...]
> That's true too and Alan I _really_ appreciate that
> you are the only Sun employee to admit that. But I
> think the reality is that OpenSolaris has made no
> progress whatsoever and when I say that I will not
> ignore defining and quantifying it -
> 
> So let us see what was the prime objective of
> OpenSolaris - Increase use of Solaris (Use It), Let
> the community contribute improvements they need and
> love ( Improve It ) and spread it so we further
> increase use and community
> contributions(Evangelize).
> 
> 1) Community participation has remained very low. To
> date greater than 90% (very unscientific and
> conservative estimate) of OpenSolaris changes are
> driven by Sun's business interests and they come from
> Sun employees. (Look at commits, look at general
> development direction - nothing there for more x86
> drivers which is what community might benefit from)
> 2) People do not feel they own a bit or two of
> OpenSolaris. That feeling remains totally with Sun.
> (People have expressed this elsewhere in GPLv3 and
> Community Participation threads)
> 3) Contributing changes remains hard (Everyone agrees
> and does nothing urgently about this - I am tired of
> hearing it is getting fixed) 
> 
> I clearly see this as failure in meeting all
> objectives.

I disagree.  I'm using it (well, a fairly current SXCR rather than
having just stayed on Solaris 9, which I already had media for),
which aside from the changes that more or less accompanied
OpenSolaris (like the SX program), I wouldn't be.  I got a tiny
little thing that's annoyed me more than once (a missing library
function) put back.  Yeah, it was tediously bureaucratic, but that
was almost entirely a matter of a disciplined process that results
in a well-engineered product; at the very least, it didn't strike me
as arbitrary.  And having been through it, something equally simple
should be a breeze next time (although I'd _expect_ to have to make
a heck of a case if it was something big and tricky).

> What should Sun do about this? Get out the way. It's
> really that simple.
> 
> a) Open all the bits (no binary blobs for the main OS
> and libraries. No dependencies which cannot be
> fixed/modified by people other than Sun employees

I think someone was looking at IBM's open-sourced i18n
code to see if it might be adaptable as a replacement
for the closed-source i18n code in Solaris now.

The ksh-integration if it proceeds that far should eventually
replace (at least on any truly new platforms) the proprietary ksh88.

I haven't followed everything by a long shot, but I'd gather progress
is being made in other places too.  Some of the stuff _can't_ be opened
short of rewriting it, which is expensive and with limited resources,
affects other priorities that people want.  Progress _is_ being made,
it's just not an all-at-once thing.  You want to pick one that particularly
bothers you and work with some folks to find out the status and rewrite
it or port a compatibly licensed (BSD and some others, even if not GPL)
version?  Go for it.

> b) GPL v2 it ! (Ok, we can settle with v3 if it comes
> to it). Encourage sharing of source both ways - it is
> the most logical thing to do. Like Alan said you
> cannot ignore Linux however you would like.

Even if licenses weren't an issue, objectives are.  Although
Linux runs on an incredible range of platforms from iPods and phones
to lap/desktops to servers and supercomputers, it's first focus is the
desktop.  And it's less interested in backwards compatibility, and doesn't
really want anymore than it absolutely has to have to do with proprietary
(3rd-party, tied to hardware where the driver would help someone to
reverse-engineer the hardware) drivers.  And its engineering discipline,
although far better than in its earlier days, is still largely self-taught.
Solaris (whether Sun's distro or OpenSolaris) comes from somewhere else,
where specialized desktops, servers, and appliances rule; where you do
what you have to do to support what _paying_ customers want (which
includes stable driver interfaces and no problem with proprietary drivers);
and where being rock-solid, highly backwards-compatible, and compliant
with platform-independent standards (like POSIX/SUSv3) trumps simply
scratching an itch.  Not that that precludes radically new stuff
(Dtrace, ZFS, Zones).  But it means new features have to be mature
enough to use and have to uphold reliability and compatibility.  The
community, expectations, and discipline are quite different.  And in
a lot of cases, even if there were no licenses, one couldn't trivially port
drivers between Linux and Solaris anyway, at least not without adaptor
code that would always make a foreign driver a second-class citizen
(in terms of performance, if nothing else).

> c) Let people control changes in OpenSolaris. Let
> some one unrelated to Sun setup a SCM and create a
> fair, inviting and truly open development model where
> people can feel they can have a say and drive things
> and they can be free to drive the development
> according to their needs

I think blastwave already has this to some degree for the polaris (PowerPC)
port.  Major stuff like that typically seems to get done in a branch, and
then integrated back in (which may take some update to catch up to the
moving  current build).  There's nothing that I can think of preventing _you_
from doing this now.  The independent distros (Schillix, Belenix, Nexenta,
what else did I forget) probably are doing pretty much that already, I think,
although they're more about getting it done than begging people to join
them.

> d) Let Sun pull changes they  need from the open,
> independent tree. And let the independent tree pull
> changes they need from Sun's development. No conflict
> of interest.
> 
> The need for independent ecosystem for OpenSolaris
> stems from very simple to understand human nature -
> No sane person likes to work according to some one
> else's needs, wants, priorities and on someone else's
> conditions, especially when they are working for
> free. It kills the whole "open" spirit.

Sane is participating to further a common objective; in
my trivial case, I didn't have any problem with that.

Is letting feelings get in the way of practical results sane?
I don't know.  It's sane enough to give consideration to the
feelings of others, but not sane to be ruled by them to the
detriment of your long-term interests.  Is there enough of the
former, or do you really see yourself as some sort of victim here?
How can you possibly be a victim if you've already been given an
unprecedented amount of goodies, and nobody is stopping you
from doing your own fork right now if  you feel like it?

> So long as Sun asserts control over this (or even
> Java) project this isn't going to get any different -
> Sun making most changes to Solaris, driven by their
> business needs and very insignificant ( both numbers
> and change magnitude/impact wise) community
> contributions. 

Assuming ksh93 integration proceeds (and as long as it's done
well, I don't much care if that means it took a year or so longer
than I might like), I wouldn't consider that minor.  Ditto the PowerPC
port.  Ditto community participation with BlueTooth and USB camera
drivers (sometimes using as starting points the *BSDs, which are enough
more similar to Solaris than Linux is that it's not only that there's no
license problem there, it's also likely to be technically easier).  And simply
having the Sun developers and outside folks talking directly with each
other has gotten some things done that wouldn't have otherwise been
done.

Has it equalled Linux in device or platform support?  No, of course not.
But even if it were GPL'd and everything else you suggested had been
done right from the beginning, I don't think we'd be there, nor even
catching up in those areas all that much more quickly.

That said, there's certainly plenty to streamline, a lot more work on
community based SCM to do, getting some non-Sun committers (which
AFAIK will happen eventually).  Give or take the license, much of what
you want seems to be happening, if slowly.   I'm just not sure what
you're _really_ missing, at least not that isn't already on its way.  You
want to grab a copy of the source, set up your own CVS or SVN server,
check it all in, and go to town?  Go for it.  Nobody's stopping you.

As for numbers, it would surprise me if there would anytime soon (if ever)
be more than a fairly small minority of changes from outside Sun.  They've
got lots of talented people, and lots of experience working with the code
base (which after all, they created, together with AT&T, and I suspect
Sun did the lion's share of a lot of SVR4 as well as just about everything
between then and now that didn't come from external open source).

Now maybe if, in addition to streamlining the process,  the creation of
what amounts to a training program for working on the code (as well
as familiarization with the process and so on) would help get more people
involved.  It could be CBT, but with certain parts  graded or assisted by
real people.  The first few through would be "train-the-trainer"; beyond
that, everyone that did well enough and qualified by other sorts of
participation would be encouraged to be part of the informal instructor
pool for at least a few other people (enough to provide for growth after 
attrition).  There appears to be some open-source CBT software out there,
so the website wouldn't neccesarily have to be maintained by Sun (although
most of the raw content for the course material, and plenty of involvement
in how to organize the course, would just about have to come from them).
In other words, creating the course could itself be a community project.
 
 
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to