standards track for FD.o (was Re: Allowing apps to install packages)

Aaron J. Seigo aseigo at
Sat Mar 4 02:48:27 EET 2006

On Thursday 02 March 2006 18:19, Glynn Foster wrote:
>  Forgive me is there is a load of inaccuracies in this mail - I
>  unfortunately missed out on the desktop architects meeting at Portland,
>  so some of this might have already been discussed there.

we actually did discuss it.. it appears you are not the only one thinking / 
feeling this way. in fact, i'd go so far as to say that *most* of us are 
thinking / feeling this way...

and thus we have a perfect segue into introducing the results of that 
discussion to this list (and the FD.o community).

the lack of ability to declare standards properly, the lack of facility to 
turn these community standards into standards that are consumable by industry 
and the political fiascos that arise from time to time due to this inability 
to act in a timely and proficient manner caused us to write the attached 

please read and comment. if there is general support for it, let's nike[1]

[1] just do it ;)

Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (
-------------- next part --------------
<title> A Working Proposal</title>
<h2 align=center> A Working Proposal</h2>

<h3>Why and The Status Quo</h3>

<p> was created by our community for our community: the open source desktop. We enjoyed a rapid succession of early successes and have had a continued stream of commonly useful specifications and technologies emerge from it. Most importantly, was erected to reflect not external needs and requirements but our own processes.</p>

<p>We do recognize that the current organization, as such currently may or may not exist, is sub-optimal. However we also maintain that the concept of a shared technology incubator is in itself valid. Therefore we make the following proposal to steer towards being a more practical and productive place for the creation and improvement of shared technologies. This will in turn result in the happy by-product of providing a more coherent set of products for our users, industry and 3rd party developers.</p>

<h3>The Proposal, Part 1: Stakeholders First</h3>

<p>Web based collaboration software will be provided at wherein individual participants from projects engaged in open source desktop development may create identities. These identities will then be used to mark the interest and implementation level of the respective projects in the specifications and software available on  This will raise the visibility of participation (or lack thereof) in specific approaches and allow reporting and change notification to be automated.</p>

<p>Combined with responsible introductions of new specifications and technologies, as a community we will be able to measure the status and health of any given technology when it comes to shared support. This in turn exposes consensus or lack thereof. Once a given specification has reached a critical level of support, currently generally defined as having the support of both of the primary desktop projects (KDE and GNOME) as well as any primary stakeholder projects (e.g. for X related technologies), then these technologies will be handed off to a standards body for formalization and announcement. We propose the FSG and OSDL respectively for these formalization activities.</p>

<p>The goal is to add as little overhead as possible to the processes while allowing us to easily monitor collaboration and measure when a given technology has matured to the point that it can and should be codified.</p>

<h3>The Proposal, Part 2: An Organizational Committee</h3>

<p>A committee made up of members from the leading desktop projects will be formed to aid in communication and, when necessary, conflict resolution that may arise around activities.</p>

<p>We recognize that the majority of open source desktop developers are generally supportive of but lacking in time and motivation to keep up with every development at Therefore the committee will provide community triage to ensure that the proper people from the relevant communities and spheres of influence are involved. This will ensure that the proper people are involved allowing the stakeholder-driven process to work.</p>

<p>As an institution, the committee will not itself make technology decisions nor steer the specification processes, though individuals on the committee may be personally involved in various efforts.</p>

<h3>Measurements of Success</h3>

<p>Near term success will be measured in the level of support for within the open source community and the rate and quality of specifications that emerge. Mid-term, the level of satisfaction of open source desktop users and ISVs will be an important metric.</p>

<p>But the ultimate measure of success will be found in the enjoyment and energy levels of those participating in as it is from that wellspring that the momentum we are all looking for will emerge.</p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : 

More information about the xdg mailing list