Re: 2.4 Proposed Modules - 2 weeks left

[Havoc Pennington <hp redhat com>]

On Tue, May 06, 2003 at 03:33:32PM -0400, Janina Sajka wrote:
> i must confess I'm having a pretty hard time coming to terms with being
> characterized as "just a marketing bullet point." Ouch.

The point is that by not including epiphany, you have not actually
improved accessibility. So I don't see the value of excluding it,
other than what you get to say in brochures.

How does it help me or anyone as a user if epiphany is not included?

> But, let me return to the central question: What are the criteria for
> inclusion?

We should distinguish two things:

 1. criteria for inclusion

 2. criteria for evaluation

Criteria for inclusion should be a) the big picture correctness (are
we including something that's a subset of the end goal, that fits in
to the overall architecture of the desktop and OS including a11y
architecture, and that we want to stick with for foreseeable future)
and b) whether it is a net gain for users.

Criteria for evaluation should be much broader.

> How about the license? Is a proprietary license acceptable? In other
> words, is open source also "just a marketing bullet point?"

To put criteria for inclusion in objectively-evaluatable terms, we
can ask: to finish this app and arrive at the end goal, would we build
on it or rewrite it? If the answer is that we would build on it, and
the app is already useful for a lot of users, then we should include
that app. If the answer is that we would replace it, then we should
not include it. We should also look at alternatives: is there some
better foundation to build on?

Licensing is a criterion for inclusion because we would not build on a
proprietary codebase; we would replace it. In other words, proprietary
code is not a subset of the code we want to end up with eventually.

> If there are no consequences--doesn't matter that you haven't even
> considered how you get to accessible because something is better than
> nothing--then how can we trust, we for whom this is a basic issue
> determining whether or not we participate.

It *does* matter whether code is accessible. That is part of the
criteria for evaluation of alternatives.

For inclusion, it *does* matter whether the code is a good fit for our
overall a11y architecture. Which means things like using GTK+ and
being willing to take a11y patches and link to appropriate libs to get
a11y.  Would we need to replace much of the app in order to add a11y?
If so, we don't want to build on it, we want to replace it.

It does matter whether we are making progress toward improved a11y and
100% a11y. We need to pressure maintainers to do the right thing.
We do that pretty effectively on the UI front also.

*However*, feature-based criteria for inclusion don't make things
happen faster. On the contrary, they cause indefinite delays.

Windows XP is a total overhaul of 98, and Longhorn is a total overhaul
of XP. There is rapid and serious innovation happening there. We are
meanwhile seriously advocating *not having a web browser* in our
desktop.

We can't freeze innovation for any feature. The features that happen
are the ones that people make happen. If you want a specific feature
to be guaranteed, you need to get the resources applied to it and be
sure it gets done.

Note that individual OS vendors may still have feature-based
releases. That means they are either willing to invest paid resources,
or accept indefinite delays, or in bad cases both. That's
fine. However, we are a free software project, and we don't have those
options. Not if we want to succeed.

Havoc