Subject: factors to consider for the Mac port
From: Paul Rohr (paul@abisource.com)
Date: Tue Feb 08 2000 - 18:50:11 CST
Wow! While I was out of town for LinuxWorld, there was a huge flurry of
traffic from folks discussing how the Mac port should be done. This is very
cool.
As best I can tell, all of the following issues are currently in play:
- which MacOS flavors (7.x, 8.x, 9.x, or X.x) to target
- which APIs (Classic vs. Carbon) best reach these targetted users
- the framework holy war (PowerPlant vs. Toolbox)
- other toolchain questions (compiler version, build system, etc.)
I'm not a hard-core Mac developer, so I'm happy to defer to whatever
technical consensus comes out of these discussions. There are many
practical tradeoffs to be made here, and I'm not going to be writing that
code. You are. What's important is that you come up with workable
solutions *you* can continue to live with.
However, here are some general guidelines you might want to consider:
1. Choose solutions which favor people's existing hardware.
============================================================
There is a very large existing installed base of Mac users who'd love to
have great word processor file format compatibility in a lightweight
product. Of those users, what combination of hardware/OS level do you think
is typical for the people who need AbiWord the *most*? Are they running
spiffy new blazing-fast boxes with the latest Carbon beta? Are they iMac
users who are dissatisfied with whatever Works version was preinstalled? Or
are they still stuck with a 7.5 box from four years ago?
Obviously you have to draw the line *somewhere*. If it's any help, here's
what other platforms have chosen:
Windows -- Win95 or later
Unix -- anyplace the latest GTK runs well (with GNOME as an alternative)
BeOS -- stick to Release 4.5 (the latest)
Note that in the latter two cases, the belief is that there *is* no
significant installed base of users on earlier versions. Essentially,
earlier versions of both GUIs are so unusable that there isn't a significant
installed base who are (economically or technologically) stuck on those
earlier versions.
By contrast, the Windows developers *have* made an explicit choice to ignore
a real-but-dwindling installed base of Windows 3.1 users. Those folks won't
be able to use AbiWord until somebody shows up who's willing to write the
necessary code to back-port to the necessary earlier APIs.
2. Try to hold down the cost for additional Mac developers.
============================================================
It's always convenient to take advantage of the latest and greatest
development tools that developers on your platform like to use. However,
this is an Open Source project, so you may get help from more developers if
you choose development tools that every potential contributor is likely to
have, rather than the version Metrowerks starts selling for big bucks three
months from now.
For example, it's pretty rare to find an active Windows developer who's not
using either VC 5.0 or 6.0, so we chose 5.0 as our base supported level.
Supporting both versions occasionally leads to build failures (because the
compilers and Windows headers differ slightly), but that's been manageable.
To date, no Windows developers have showed up to add support for other
Windows compilers (such as the free DJGPP), but when they do, we'll
certainly be willing to integrate those patches.
By contrast, on Be and Unix there really isn't much of a compiler choice,
since everybody uses what ships with the OS.
3. Avoid legal minefields.
===========================
If there are other reasons to go with PowerPlant, then someone will need to
do the legwork to make sure that the license on those sources is
sufficiently GPL-compatible. I haven't seen a copy of that license, but it
looks like this may be a non-issue:
http://www.abisource.com/mailinglists/abiword-dev/00/February/0073.html
When it comes to questions about GPL compatibility, anything RMS says tends
to be taken as gospel, so he takes pains to be as precise as he can when
answering specific questions. More general glosses can easily be
misinterpreted.
Thus, before anyone decides to ship a PowerPlant-based version, I'd really
appreciate it if anyone could either point me at a publically-available
pronouncement from RMS on this specific topic, or forward me a copy of any
private mail so I can follow up with him.
4. Code wins.
==============
Of course, the important thing here is to get a working port up and running
for everyone to play with and start adding to. There are a number of people
interested in helping achieve this goal, and discussions both on this list
and in private play an important role in coordinating everyone's efforts.
However, please don't feel like you have to have absolute consensus on every
issue before diving into the code and seeing what works. If you believe in
whatever approach you're advocating, and feel confident you can finish it,
by all means write the code.
5. May the best code win.
==========================
As with any Open Source project, it's entirely appropriate for two sets of
people who can't agree on some issue to each go off and code it their way.
If one of the solutions is clearly better, that ought to become obvious
pretty quickly in the usual Darwinian fashion.
Like anyone else, developers and users tend to vote with their feet. :-)
Paul,
over-stating the obvious
This archive was generated by hypermail 2b25 : Tue Feb 08 2000 - 18:44:50 CST