Development project priorities
Development projects are often required to make hard decisions about where to apply their effort; developer and tester time is a scarce resource, so choices must be made. It is not uncommon that those choices will be unpopular with some, perhaps quite vocal, segment of the user community, but users need to recognize that prioritization has to occur. Free software projects, even those backed by foundations or corporations, are obviously not immune to the need for focus. A recent discussion about Mozilla dropping support for Mac OS X 10.4 shows that some users still don't quite understand the issue—especially when it is their platform that will be affected.
It all started with a post by Mozilla's Josh Aas about making a final decision on whether to support Mac OS X 10.4 ("Tiger") in the version of the Gecko rendering engine that will be the basis of the next Firefox release (3.7 or higher). He listed statistics of the number of Mac users that still use 10.4, which was released in 2005, and noted that there were significant hurdles to continuing to support that release in the codebase. Furthermore, he pointed out that there will be a roughly yearlong transition period:
But that didn't sit well with some Mac users. Phillip Jones argued against dropping support because it would require hardware and/or software upgrades—at a substantial monetary cost—for those who still use 10.4. He also claimed to be speaking for lots of others:
Others chimed in to agree with Jones, but anecdotal stories about individuals who are unable to upgrade doesn't really help in the decision. Mozilla's Asa Dotzler points out the kind of information that would be useful:
Dotzler continues by noting that the decision is not being made lightly, nor is it being made in a vacuum, but some kind of prioritization needs to take place:
That means we have to pick our target versions carefully. Do you have some suggestion about what that cut-off should be that goes further than "not the platform I'm on" ?
Many of those who are against the change are making a "not in my backyard" (NIMBY) argument, as Dotzler points out. Others believe that because Mozilla gets millions of dollars in revenue, it should plow some of that money into supporting 10.4. It is not a terribly reasonable argument, as organizations should be able to make their own decisions about staffing and such. It is also a bit ironic that folks claim that Mozilla should support them in ways that Apple will not.
The real problem stems from Apple's decision to only support 10.5 ("Leopard") on some PowerPC Macs, and to only support 10.6 ("Snow Leopard") on Intel Macs. In addition, Apple charges for each upgrade, which potentially leaves those who are financially strapped behind. It is not particularly fair to blame Mozilla for something that has its roots in Apple's upgrade strategy.
Those calling for Mozilla to go the extra mile for 10.4 are really asking
for a "disproportionate investment
", according to Mozilla's Boris Zbarsky. In
addition, they haven't made a good case for why that should be:
"No one has cited a good
reason why 10.4 users matter more than 10.5 or 10.6 users or Windows or
Linux users.
" There are technical reasons why support for 10.4 is hard,
as Aas outlined at the start of the thread, so there needs to be a
compelling reason to do it.
Allocating resources is a difficult problem sometimes, but one gets the sense that Mozilla developers are pretty convinced that 10.4 is not a good use of their efforts. Mozilla VP of Engineering Mike Shaver also points out that Apple seems to have left 10.4 behind:
It would be easy to write this off as a problem for folks that have chosen a proprietary operating system, but this same problem is regularly faced by those who run free systems. Projects frequently make decisions on their focus: distributions choose architectures to support, applications choose which features to implement or what desktop to support, and so on. Users need to find a way to make reasoned arguments about what they would like to see happen, while understanding that the project itself gets to make its own decisions. On the flipside, projects need to provide a means for users to give their input, hopefully in a constructive manner.
Advocacy—along with venting—in bug reports was another problem discussed in the thread. "Piling on" to bug reports and feature requests is a common reaction for users who are frustrated with the choices a project is making, as we saw last August for KDE. More recently, the addition of CNNIC to the Mozilla certificate store also had many impassioned users commenting on the bug, but without providing the kinds of information needed by the project to assist its decision making process.
Some kind of balance needs to be found, where users feel like their voice is being heard, without overwhelming the developers and project leaders who are trying to do their jobs. For free software projects, though, there is a potential solution that is not available for those using proprietary systems: the code is available if someone wants to put together a project to go a different direction. While some Apple users will never be able to run more recent versions of Mac OS on their hardware, they most certainly could put together a project to continue supporting Firefox on those older versions. It would be a lot of work, but that's a much better situation than for Mac OS where it would simply be impossible.