Re: A strawman proposal for X.org & XFree86.org

Hi,

Thanks for getting this started. If we can come up with a good
proposal for a healthy combined XFree86/X.org organization, I'd like
to offer to bring the software and draft specs at freedesktop.org to
the table, as something we'd initially import into this organization.
This is subject to agreement from freedesktop.org participants of
course.

On Thu, Mar 27, 2003 at 11:06:17PM -0800, Alan Coopersmith wrote: 
> X.org members may:
>    - Participate in the creation or modification of X Window
>      System standards and X.org steering committees.
>    - Vote in X.org elections or run for office.

One thing that I consider important is to have the same
membership/elections/governance for the implementation project and the
bulk of specification-development/communication work.  Ideally, we
would not institutionalize a split between those as it just encourages
snafus.

On the other hand, a split between the project where most of the work
goes on, and a body that does rubber-stamp standardization and
certification, may well make sense.

===
Let me clarify "rubber-stamp." By this I mean essentially what free
standards group does for the LSB. They create clear documentation and
test suites for existing de facto design/implementation, fixing the
implementation only if it is clearly not right. e.g. if the big
picture of the spec says that you have to be POSIX compliant, you
would fix the implementation rather than making the spec require
POSIX-violating behavior. But no really significant changes are made
on the LSB level, and any changes made on the LSB level effectively
have to be signed off on by the maintainers of the involved software.

"rubber-stamp" does not mean doing nothing. Rigorous docs are needed,
agreement on what to include in a spec at all is needed (what is ready
to set in stone, vs. what is still in flux), test suites are needed,
and a certification process and logo are needed. A formal standards
body should provide those things. However, the formal standards body
should not be changing the technology in significant ways, or making 
big-picture decisions prior to de facto consensus.

So I'm saying the bulk of what a technical working group would do
should go on inside the implementation organization. The formal
standards organization should only kick in once things are pretty well
ready to be set in concrete.

> Membership is free, and open to any individual who has contributed
> to the development & adoption of the X Window System standards
> or to a recognized open source implementation.

Perfect.

> X.org sponsors may:
>    - Submit hardware and/or software products to the X.org
>      laboratory for compliance & interoperability testing.
>    - Access the X.org lab to debug interoperability problems with
>      the equipment provided there.
>    - Participate in X.org publicity campaigns.

These are definitely consistent with a "rubber-stamp" standards body.

>    - Provide a representative to the executive board

If the executive board is the board of directors of the corporation, I
believe it should be elected by the membership. If companies can buy a
seat, they can effectively buy control of the whole organization.

The other problem is that this effectively grows the board without
bound, right? An effective board is going to be maybe 9 people, maybe
14 at most, something like that. Which is a reason to elect a fixed
number instead of having guaranteed seats.

> Sponsors may contribute a portion of their sponsorship fee by
> donating services to X.org or the open source implementation.

Good feature.
 
> XFree86:
> --------
... 
>   - Maintainer: A developer who has been granted access to commit changes to
> 	a specific part or parts of the XFree86 software.
> 
>   - Core Team Member: A developer who has a consistent record of contributing
> 	to technical discussions on the developer lists and/or contributing
> 	code changes that enhance XFree86.

I don't really see the reason for the core team vs. developer
distinction.  The structure you want in order to scale can be
described as a "confederation of module maintainers." For example, we
might import the D-BUS project into this new X CVS. Then those of us
working on D-BUS would own that CVS module and participate as the
maintainers of it.

Similarly, we might create modules for current bits of the X tree that
have active developers. For example, we might have a module for xterm,
since lots of people hack on that and it effectively has its own
maintainers. We might have a module for Keith's font libraries. 
We might have a separate module for certain drivers. etc.

Module maintainers basically have final say over their modules, except
when we need to coordinate the big picture, such as to make a release
and set release schedules. And when you need to coordinate the big
picture, you need everyone to feel like they're on a level playing
field and their module is equally represented.

===
Where I would make a distinction is not on the level of maintainers
vs. core maintainers, but instead on the level of modules included in
a particular release, vs. those not included. You can have multiple
releases; for example, there might be a "drivers release" including
driver modules, and there can be releases of just individual modules.
The really big global technical decisions to make are about what
modules to include in the release of "The X Window System" as a whole,
right.

When we have these large coordinated releases, decisions about them
should stem from the group of module maintainers involved, though they
can and probably have to delegate to a release manager or team.

Experimental modules can definitely exist that aren't in any release
group yet. 


=== 
Commit access isn't the only thing; all module maintainers need at
least some access to full hosting services, such as a web site,
bugzilla, mailing lists, etc. for their modules as they see fit, and
basic ownership of their usage of those services. So I would not
define CVS commit access as the only developer vs. maintainer
distinction.
 
> Upon the release of X11R6.7, XFree86 shall integrate the X11R6.7 code
> into their code management system as the base of the "X.org Standards
> Sample Implementation" (SSI) branch.

OK, this is where I think the strawman is really off-base. It means we
have an external organization doing a *lot* more than just formal
standardization in "rubber-stamp" mode.

We should all get in the same boat, assign the best people to the
right roles, and work together to keep it above water and moving
forward.

The XFree86 project should absolutely be producing a good and
reasonable stable branch on a regular schedule and maintaining it
according to rigorous policies. There's no reason it can't; many open
source groups do. Having a separate stable branch maintained by an
X.org committee is just really strange and will encourage ongoing
fragmentation and encourage people to take their toys and go home
instead of creating a unified X community.

If specific vendors have special needs, they can create a special
vendor branch, or a patch set (such as "sun-patches" on
cvs.gnome.org). But this shouldn't be institutionalized in the
structure of the organization, and large divergence between vendor
branches and the mainline should not be encouraged.

The standard, unpatched XFree86 stable branch should be completely
usable and shippable by vendors that choose to do so.

It's like the Linux kernel; there are many forks, but ultimately they
are all feeding back into Linus's tree, and once it's clear some code
won't make it into Linus's tree that code typically dies.  Similarly,
we should have a canonical tree, and stuff that doesn't make it into
that tree should be counted as a dead end.

>  Changes that would change an existing standard or require the
> adoption of a new standard will not be incorporated into the SSI
> tree until approved by the X.org Architecture committee.

This is part of why this branch is broken; things should be deployed
first and rubber-stamped second. Otherwise you standardize broken
stuff that hasn't seen real-world testing.

> User Fox is convinced that the truth is out there and that everyone should be
> helping in the search for alien intelligence.  To do this, he wants to add
> a new extension to X, the "Force Idle Loops to Execute SETI@Home" extension
> (X-FILES), which he wants to become a recognized X standard.  There will be
> two paths to doing this:

Groan! ;-)

> Path B (Uniform Standards allow easier cross-platform development):
>   1) Fox creates a spec and submits to the X.org Architecture committee.
>      They decide to create a working group to study this.
>   2) All interested parties join the working group and discuss the proposed
>      spec.
>   3) A sample implementation is written to implement the spec in XFree86.
>   4) Fox submits his changes via the XFree86 bug tracking system, where they
>      are reviewed by a maintainer.  Since these changes introduce a new
>      extension & API, the maintainer asks the Core Team for their opinion.
>      The Core Team either agrees to accept the extension into XFree86, or
>      to allow it only into the X.org SSI branch but not into the XFree86
>      branch.

Path B should not exist, especially point 4) of it. The whole point
here is to have, as the GNOME/KDE statement phrases it, "a single
source of X innovations."  If we can have ongoing disagreement on
whether a standard is official, or worse, long-term divergence in
which solution is chosen for a particular problem, then we haven't
achieved that goal.

But on a larger scale, Path B encourages and institutionalizes broken
behavior. Devel teams used to the proprietary model need to be
carrot-and-sticked into learning to do things in a way that enables
effective cross-company/globally-interesting development progress.

I think it's been made abundantly clear over the past 5 years that the
open source model has crushed the CDE/X.org model in overall results.
Encouraging people to stay stuck in the model that doesn't work is a
bad idea.

If you went down Path B, what would happen is that all the module
maintainers doing active work would ignore you until you had the
sample implementation. And then they'd say "well you're going to have
to rework and iterate this in light of our feedback, or we won't
accept it." And people won't have been expecting that. They'll then
expect to be in the SSI branch, but the primary branch would reject
them. And we'd get long-term divergence.

So Path B is a trap for the unwary. It needs to be clear up front,
that if you want to develop a feature to be used by the toolkits, you
need to go iteratively work with the GTK+ and Qt and Swing
maintainers, *not* only talk to Sun, HP, and IBM.

If you want a concrete example: fontconfig/Xft went via Path A, and 
STSF is going via Path B. Now we have a huge mess. By having only one
path, you avoid that, because the same people would have been involved 
in both projects and could have said "hang on, let's unscrew this."

===

The most important point is probably that the X.org branch and the
XFree86 branch should be unified, there shouldn't be one stable branch
maintained by X.org and one by XFree86, we need to create a single
community. We need to all take the leap into the same boat and then we
will be motivated to fix what needs fixing.

I don't believe the open source X community has anything to gain by
acknowledging the legitimacy of a second source of X innovation.  If
there are two, I believe GNOME and KDE and other open source projects
should make a formal joint statement that we support the open one and
will use its innovations to the exclusion of the closed one's
innovations.

Avoiding this conflict hurts too many people and slows progress; the
hard decision should be made.  People need to know where to go to
develop an innovation.

So summary of my feedback:

 - only one official shared stable branch.
 - no way to buy a board seat.
 - if there are two organizations, one should be rubber stamp.
   and certification only, not development of either code or specs.
 - no Path B for development of innovations. One standard path.
 - modularization of the code (and resulting modularization 
   of authority) is key to scaling the project.

Thanks for your time, as always I apologize for email lengthiness.

Havoc