Re: Dropping Mac OS X 10.4 support in Gecko 1.9.3

On Tue, Feb 9, 2010 at 8:17 AM, Gervase Markham <gerv@mozilla.org> wrote:
> On 07/02/10 16:25, Boris Zbarsky wrote:
>> Wouldn't help in the timeframe involved here.
>>
>> That is, if we hired more people _today_ they would not be up to speed
>> in time to help.
>
> But perhaps we should hire people today so they would be up to speed in
> time to have an effect on the decision, when it comes, to drop 10.5 support?

Should we?  What amount of resource should we divert from other areas,
such that we can support a small-and-shrinking number of users on a
trailing edge version of a deeply-minority platform from which we get
decreasingly poor support from the OS vendor as it ages?  (When we
report even *security-related* bugs in older system libraries to
Apple, we often get a pretty cold response.  This may not be a problem
that the WebKit or Safari teams face, but I can't really know for
sure.)

As an example: you could spend from now until the end of the year
learning to be a Mac developer, so that we would have another Mac
developer available (and on the Foundation's staff, no less!).  That
would be at some cost to the project, in that your governance work and
such would be left undone.  (Or we could hire someone else to do that
governance work, but then why not train them ALSO to work on the Mac
instead?)

To talk about this in terms of being a simple matter of isolated
impact on Mac code or Mac developers is facile, in my opinion.  The
code complexity in question impedes work on improving code (text,
plugins, graphics, performance) for all users, Mac and otherwise,
creates additional test, release management and infrastructure burden,
and all the other ancillary costs associated with keeping another
combination in mind when developing anything.

Could we bear those costs?  Certainly, at the limit: if the Mozilla
project devoted all of its resources to the Mac to the exclusion of
other platforms, we could probably even support OS 9.  At the other
extreme, dropping all Mac support but the most recent (effectively
just targeting it as a developer tool) would permit us to
differentially improve the product for Windows users.  Correct answers
for different organizations and projects and (mostly) goals lie in
various places along that spectrum: the Adium project are close to one
end, and game developers tend towards the other.  Mozilla believes
that the right place on that spectrum, in service of our mission and
objectives, has us no longer investing in 10.4 support, or restricting
ourselves to things that can be effectively/efficiently done with 10.4
APIs, for the release that follows 3.6.  People who will be
inconvenienced by that decision will obviously be upset (and vocal),
and in these cases it's much easier to concisely describe and imagine
the "loss" to 10.4 users than the "gain" for the rest of the project
and its non-10.4 users.

I'm speaking here as someone who until this week had a 10.4-running
laptop (a first-generation 2006 MacBook, with a capacious 512MB of
RAM) in his home, being used daily by a Very Important Person.  The
Snow Leopard upgrade CD for < $100, plus a $30 stick of RAM, has it
running just fine with modern software.  People with PPC Macs will
need to do the Leopard upgrade or something, but by the time 3.6 is
end-of-lifed we're talking about hardware that is at *least* 5 years
old.

>> In the long term, the main issue is that amount of work that can be done
>> scales sublinearly with number of people doing it.  So in fact putting
>> more people on an issue requires "disproportionate" investment to get an
>> improvement, after a certain point.
>
> That is true, but I contend that it's not a killer - otherwise no
> company would be larger than N people, for some value of N, because
> adding the N+1th person would make things worse, not better.

What has your experience been scaling interdependent projects, in
terms of sublinear return on additional parallel work?  Mostly
organizations scale by doing more different things, rather than
applying more people to the same sets of problems, because the
sublinearity typically comes from communication and co-ordination
overhead.  That doesn't really apply well to the case where the goal
is to have the same capabilities and application available to people
with different software contexts, in my experience.

Mike