Slashdot Mirror


The XFree86 Fork() Saga Continues

Mortimer.CA writes "An article up on OSNews about the XFree story mentioned earlier. Included is: replacing fontconfig with Sun's stsf; XFree86 co-founder David Wexelblat saying that XFree is today obsolete and should be changed; Keith Packard replying, and more."

8 of 547 comments (clear)

  1. Bad Link by chrisseaton · · Score: 0, Redundant

    I know I should RTFA before posting, but the link points to http://slashdot.org/TheXFree86Fork()SagaContinues, and that can't be right.

  2. 404 by Tribbin · · Score: 0, Redundant

    Hmm, bad link

    http://slashdot.org/TheXFree86Fork()SagaContinue s

    404 File Not Found
    The requested URL (TheXFree86Fork()SagaContinues) was not found.

    If you feel like it, mail the url, and where ya came from to pater@slashdot.org.

    --
    If you mod this up, your slashdot background will turn into a beautiful sunset!
  3. Real Link by creative_name · · Score: 0, Redundant

    Here is the real link to the article on OSNews

    Link

    --
    Posting as directed.
  4. Correct link by StrawberryFrog · · Score: -1, Redundant

    over here.

    Shameless, I am.

    --

    My Karma: ran over your Dogma
    StrawberryFrog

  5. http://www.osnews.com/story.php?news_id=3090 by Bytal · · Score: 0, Redundant
  6. Correct link by dark-br · · Score: 1, Redundant

    The correct link for the article is here

  7. Shameless repost by kjj · · Score: -1, Redundant

    A Call For Open Governance Of X Development
    Persistent problems in XFree86 development have become widely recognisedwithin the X community. I have talked to people throughout the X
    community in a search for solutions. These conversations were personal rather than public because I felt the need for council, not conflict.
    Some have suggested that this was a secret attempt to undermine the XFree86 project: this was not my intent. I have tried as hard as I can to work within the existing XFree86 structure.

    Some of the most persistent problems identified by the community are:

    Limited development resources

    The 'fetchmail' project has contributions from over 800 developers. Over the last two years there were about 250 contributors to XFree86, a project more than a hundred times larger.

    Slow release schedules

    Since the XFree86 4.2 release in January 2002, support for 27 new versions of the ATI Radeon chip was added to the XFree86 Radeon driver. Anyone using one of these chips was either forced to wait for the February 2003 release of XFree86 4.3 or run an unreleased version of XFree86.

    Lack of cooperation with other projects

    The KDE and Gnome projects were forced to form the freedesktop.org project to extend and enhance X Window System standards because XFree86 refused even to participate in the process.

    Opacity of development processes

    There is no information available on the XFree86 home page on becoming an XFree86 developer. Information for new developers consists of the mention of a couple of mailing list addresses in the README document included in the XFree86 4.3 release.

    I have made limited progress in my attempts to address these issues. The opening of the XFree86 CVS repository and developer mailing lists to public access has benefitted X development significantly. In order to improve the technical coordination with other open source projects, I have become personally involved in many of them.

    Within the last couple of months I have come to understand why these persistent problems have not been solved by the X community. By X community, I mean:

    Developers working on the X server and libraries. Developers working on ancillary X extensions and services such as the DRI and GATOS projects.
    Developers working on Qt, Gtk+, Fltk, Tk, Motif and other toolkits. Application developers using either Xlib or an X toolkit. System integrators and distributors packaging X technology in various forms. Consulting companies selling services based on X. Hardware vendors producing hardware to work with X. X End users.

    The key issue is that XFree86 is not a community-governed project.

    XFree86 processes and procedures originate with the Directors of the XFree86 Corporation. Technical leadership of the XFree86 project has
    traditionally been provided by the XFree86 Core Team, an informal association of leading XFree86 developers.

    While the XFree86 Board of Directors is nominally in charge of XFree86, they have absented themselves from governing the project and left that to the XFree86 Core Team. The community is left wondering who is actually in charge of XFree86. As a result, community trust in XFree86 leadership has suffered. Decisions appear to be arbitrary and are not seen to reflect the will of the community. The leadership has no accountability to the community: thus community members have no ability to change project direction and the Board has little incentive to do so. In addition, the lack of clear formal policies has made it difficult to resolve disputes when the usual consensus breaks down.

    It is therefore essential for the community to be involved in the governance of X development. Two key elements in a community-governed project are:

    1. A low barrier to become a voting member.
    2. Regular elections of the government by all of the members.

    Community governed projects such as Gnome, KDE and Debian have well-established membership policies. All allow anyone with the inter

  8. Wexelblat is right, network transparency pointless by Ars-Fartsica · · Score: 0, Redundant
    To 99% of the X audience, X's network transparency is meaningless. Wexelblat is correct to state (in a repsonse in the thread) that the X folks have optimized for the outlier case - the 1% of people who like the transparency features - instead of focusing on the core majority who don't need it now or ever.

    Removing network transparency would go a long way to making X (or whatever else replaces it) much more lightweight.