xf86CheckBeta() and friends

[Daniel Stone]

On Fri, Nov 12, 2004 at 09:28:14AM -0800, Stuart Kreitman wrote:
> Daniel Stone wrote:
> >It's bad because we don't want to walk this route.  It's circumventable
> >by just recompiling the thing (this scheme depended on no-one but the
> >gatekeepers having the source, and man if that isn't the worst idea for
> >X.Org), and keeping it around despite the chance to remove it would just
> >show bad intentions, IMHO.
> >
> >So, in a nutshell:
> > * only useful for the situation where the X.Org server is
> >   closed-source
> > * hopefully that never happens
> > * shows bad intentions towards our users by timebombing the code
> > * sucks
>
> I really don't understand this reasoning. It plays very circular:
> "Its bad because we don't want to  walk this route... bad intention.."
> I don't grok the highly technical postscript: "sucks". I'm afraid
> this response is fully opinionated.

Sorry, let me try to clearn this up.

It's bad because we don't want to walk the closed-source route.  The
success (or otherwise) of this function depends entirely on one party
having the source, and not distributing it, which goes against every
goal I can find for the new X.Org Foundation.

Yes, it's highly opinionated -- as I'm sure you know, I come from an
open source background, and I'm afraid I don't have the experience with
proprietary UNIX to lean me towards this approach.  The reason it's
opinionated is because the X.Org Foundation now has an incredible amount
of community respect (more than it ever lost in the first place, and
more than XFree86 had, certainly), and is now starting to become a truly
open collaboration of vendors, hackers, and high school students working
out of their bedrooms (been there, done that).  I would find it ironic
(as well as deeply saddening) if the paid vendor consortium cum
incredibly successful open project started drifting back towards the
paid vendor consortium paradigm.

If we move to this model, it is a highly closed model -- one
person/group/whatever holds the source, they set the terms of use, and
no-one else gets to join in the party.  It just goes against every fibre
of open/community of development I can think of.

> The intention of this timebomb is to protect non-developes from
> inadvertant deployment of the Beta version with the associated
> risk of  frustrated users and support calls.  One could argue that
> effective use of version control can  achieve the same effect in a
> less obtrusive manner, or that there's a security risk. I don't know.(tm)

I absolutely understand this concern -- I see why the code was put
there.  On the other hand, if it is deployed, either people will just
deliberately sabotage it by recompiling, or extending the delay since
the algorithm is open, or whatever.  I also think it reeks of a
disrespect to our users -- 'sure, you can use our server, but only on
our terms; welcome to our upgrade cycle!'.  To me, it smells of vendor
lock-in, and I dislike it immensely.

Again, I'm sure the intentions are good; but (as a developer,
distributor, and someone working on converting his mother to using open
software) I'm just as sure the effects are bad.  And the community
perception even worse.

-- 
Daniel Stone                                            <daniel at freedesktop.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20041112/df897cb6/attachment.pgp>