On Jul 25, 2005, at 4:20 PM, John Plocher wrote:
> Keith and Roy's conversation about ksh...
Keep in mind the "traditional Sun/Solaris development model"
that we are trying
to seed our community with:
Germinate an idea into a plan,
Commit to that plan from both resource and technical perspectives
(do we _want_ to do it? and
is this the _best_ way to architect it?)
Develop/implement to that plan
Integrate the result into the "FCS all the time" shared source base
How does this differ from "other" FOSS projects? Primarily in the
proactive nature of the "commit to a plan" before starting, and
"requiring that a project be complete" before allowing integration.
Er, kind of, if you completely ignore the presence of stable/unstable
branches in the source code control system and the versioning policies
that govern the release process. If what you mean to say is that
Solaris follows a waterfall software design process that was popular
in the late 70s through 80s, then I would agree that is different
from collaborative open source projects that depend on iterative
development processes and non-linear release strategies.
The former is simply good software engineering - know what you want
before you start hacking; the latter helps us avoid the reactionary
integration fire drills that often accompany "not ready for prime time"
putbacks/commits.
Sorry, the former is not "simply good software engineering" -- it
is merely wishful thinking combined with centralized control.
Sometimes it works great, sometimes it fails miserably, and almost
all the time it fails to meet customer requirements when they
actually wanted them to be met (back when they asked for the feature).
There is a ton of software engineering research on that subject.
Good software design is a process of discovery that is never
"complete".
The latter constraint of "requiring a commit be complete" is
just as true for collaborative open source projects as it is for
Solaris. Most open source projects are distributed on several
orders of magnitude more platforms than Solaris, and thus sometimes
don't discover a problem exists until it is distributed to some
platform not owned by a developer on the project, but a general
rule in Apache is that a change must be complete within the branch
and platform on which the developer is working before they are
allowed to commit even to an unstable branch.
[... skipping the ARC review description because it was an example
of a business decision, not a technical decision.]
Continuing this "model the expected behavior" example, now that we have
a committed plan, what would we do next? One possibility:
Create a teamware child workspace (or CVS branch or ...)
Gather a group of interested developers together to work
on this project
Seed this workspace with the ksh93 sources
Get it to work
Start building in the "dual mode" behavior
Develop - Test - Iterate... until complete,
Request permission to Integrate the changes back into OpenSolaris
Integrate/Putback/Commit...
Alternatively, OpenSolaris could give development autonomy to the
communities, wherein technical development, discussion of alternatives,
getting it to work, and testing can all take place independent of
any ARC review. ARC review isn't needed until the community wishes
to apply the completed work to a stable release branch, at which
point the community product does need to adhere to the particular
interface requirements for that branch. [They are, of course, aware
of those requirements during the whole process, and thus will have
designed and developed for a particular set of branches.]
It makes more sense for an OpenSolaris community to simply create
a directory on an unstable branch and iteratively design-develop-test
until complete enough for a release. A discussion should ensue on
what (more stable) branches it should be ported. Finally, the
community votes based on what they want in the branch.
Within Sun Engineering, advance review and careful description of
customer benefits are necessary because resources are limited and
need to be allocated. In collaborative open source, resources are
only limited by the number of interested volunteers and the entry
barriers they need to overcome before contributing. Description
and review of plans is always beneficial, but those descriptions
and plans can and should be adapted as development on the unstable
branch proceeds.
We can expect that Sun will contribute a majority of their effort
on projects that Sun considers to be a priority for Solaris. That
is good for everyone concerned because the end result benefits
everyone. Others can be expected to focus on their own priorities,
which is also good for everyone concerned. Resources don't need
to be carefully allocated across OpenSolaris because each group of
people are already being allocated by personal preference (with
a substantial part of that preference being determined by their
"real job").
Design review is a continual process in an open source project.
Point reviews come in two forms: code change reviews and release
versioning. Interface stability is determined by the scope of
changes allowed on a given branch release.
Sun can participate in an OpenSolaris community and attempt,
through reasoned argument and contributed alternatives, to steer
the design of a product towards a given set of interface
characteristics. Sun can also choose to release only stable
components within its proprietary releases of Solaris.
However, if we want the rest of the community to participate as
equals within OpenSolaris, then Sun must allow the rest of the
community to participate according to their own priorities.
OpenSolaris must allow projects to proceed independent of the
business requirements of any single contributor, even when one
of those business requirements happens to be interface
compatibility with SunOS 5.0.0. That cannot be an OpenSolaris
requirement because it prevents the community from building new
things that may never be part of SunOS. After all, Sun decided
to do this open source stuff because they want to take advantage
of the non-linear productivity of the open source world. You
can never predict when a feature will become so compelling to
new customers that it will justify a SunOS 6, but you can
measure it after the community has developed and deployed
that feature in cutting-edge distributions.
The only other alternative would be for OpenSolaris to become
a non-collaborative project, a la Darwin, wherein the rest of the
community is free to play with the code but only one company
determines what goes into releases. That is still open source;
just not collaborative open source.
I have been asked, by both the CAB members and Sun execs, to
propose a governance process for collaborative open source
development. Non-collaborative development is not considered
a viable option given the competition and relative success of
collaborative open source projects. I am hoping that the
development process team has kept that in mind.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/>
Chief Scientist, Day Software <http://www.day.com/>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
