On Jul 28, 2005, at 7:30 PM, John Plocher wrote:
[stop, stop, you are bringing out the verbose monster in me!]
Roy T. Fielding wrote:
BUT THAT IS THE WHOLE POINT OF THIS DISCUSSION!
I don't operate under Solaris constraints.
OpenSolaris is NOT under the same constraints as Solaris
because ... thus have no influence over Jörg's desire to provide a
future OpenSolaris version of ksh that is based on ksh93.
I think you are overlooking a very important distinction.
The question on the table is "how should the master workspace/cvs tree
for OpenSolaris be managed", and not "how should forks, clones and
other
second order derivatives be managed".
I have only been talking about OpenSolaris -- the set of
community-driven collaborative projects under that name.
*ALL* of your examples are of these 2nd order "forks". And I agree
with
you that it is not my place (nor Sun's, given the terms of the CDDL) to
dictate what you or they can or can not do with those forks. If you
want
to fork off your own copy of OpenSolaris and follow your own muse, go
ahead.
None of my examples were of that type and I have no idea where
you got that impression.
But, when it comes to putting your changes back into the source tree
called
OpenSolaris, as a member of the OpenSolaris community, not only do I
care
passionately about it, I am taking a very vocal and active role in
trying
to define the constraints in the way I think is best. Yes I am
biased, Yes
I work for Sun, and No, I'm not doing this or saying this because
someone
"told me to push Sun's position". Unless you count that I've applied
this
same passion internal to Sun to Sun's development process, and so
Sun's party
line is in some small way a reflection of my efforts. (Ok, only the
bugs
and warts. There are lots of others who should get whatever credits
there
are to go around).
You get one vote, just a like everyone else who has earned it.
Today, the rules for what can go into the gate and the process for
getting
it into the gate are still being defined - in good part by this
discussion
and others like it. At some point soon, the process will start to
change,
to incorporate the results of these discussions. And when the changes
are
complete, the community (with both Sun and non-Sun people involved)
will
be able to play all the roles in that process.
At that point, I believe we will have the following:
The CAB will have the authority to, and the responsibility of,
deciding which branches of OpenSolaris (aka consolidation versions)
it wishes to formally charter. Like all authority, it can be
delegated as needed.
Anyone will be allowed to fork copies off of these branches,
to evolve as they see fit, but those forks can not be called
"OpenSolaris". There will be a formal, defined process to follow
if you want your changes to be allowed back into OpenSolaris.
If you wish to be a part of the OpenSolaris community, you will be
expected to understand and follow some set of core values.
Conversely,
the community will enforce those values and tend to reject proposals
that do violence to them.
I hope that:
One of those core values will be "backwards compatibility is a
constraint,
not a goal". This implies that it is seen as a feature (and not a bug)
that there is no Major version development branch following the
current production branch.
I don't consider that to be a viable community for people outside
the Sun or Sun-derived payroll. The only people involved are the
ones who consider Sun's existing customers to be the target audience
(or who don't mind doing Sun customer support for free). There is
no reason for them to explore new ideas at OpenSolaris because the
platform will never be as user-friendly as the other operating
systems that are not dependent on 1981 interfaces.
You are basically making the same argument as the one where Sun
should be limited to the SPARC CPU architecture because that
interface is compatible. The problem is that compatibility is
not the only business that Sun cares about, and migration costs
is only one of the concerns of Sun customers. Sun doesn't have
a Solaris 6 in mind, yet, because Sun hasn't faced up to the
problems of obsolescence. Maybe it never will.
Companies participate in collaborative open source because
it takes them out of their shell. It encourages cross-pollination
of ideas and exposes their employees to amazingly thoughtful and
productive discussions about even the most obscure aspects of
a product. Apache mailing lists, when they are being productive,
are among the most effective means of mentoring young developers
about the importance of code reviews, modular design, careful
interface versioning, proper issue reporting, and working
productively in a group setting.
Whether or not we create a project within an OpenSolaris
community to tackle a given task is completely independent
of any interface constraints.
You are advocating starting off the OpenSolaris community on a track
that
immediately abandons this core value. I disagree (obviously), and
instead
advocate keeping the core value, and leaving the question of creating a
new major branch to the point in time where we find something that - in
our community's considered opinion - can not be done under our current
constraints.
The entry-barrier is too large for anything like that to be
effective. People will just do the interesting work elsewhere
and never come back.
Opening Pandora's box and intentionally throwing away one of Solaris's
key features seems extremely shortsighted, not to mention
counterproductive.
No, it is called leadership. The same kind of leadership that led
to the decision to make Solaris an open source product governed by
a collaborative development community. The rationale was (and is)
that the risk of doing so is understood and considered to be
preferable when compared to continuing the straight and narrow
course and permanently losing third-party developer mind-share.
I am telling you, point blank, based on both my experience within
the open source community and my research background in software
architecture, that OpenSolaris will fail to achieve the goals set
by Sun executives if you refuse to allow community members to
develop new projects within the community on unstable branches.
Furthermore, you CAN retain all of the compatibility conditions
that you require and *still* give freedom to the community, but
only if you let the community development proceed on branches
(fork within itself) instead of chasing those developers off
to other communities.
You may disagree with me, and the community may choose to ignore
my advice, but the reason I was asked to participate on the CAB
is because of my experience and my ability to express an unbiased
opinion, regardless of the prevailing winds and the traditions
held sacred by Sun. It would be damned silly for me to agree to
do that and yet keep quiet when I believe you are headed off a cliff.
The only thing we need to agree
on as a community is what the version numbers mean, and thereby
allow integrations like Solaris to choose which product versions
to include in which release.
In addition, we obviously need to agree on a set of guiding principles
and
core values.
Conformity is a double-edged sword. Be careful that you don't
create a community without diversity.
....Roy
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
