[sword-devel] Windows users as "poor cousins"?

[Jonathan Marsden]

OK, I'll bite.  Let's run with this discussion a bit...

Greg Hellings wrote:

> Most Linux or FreeBSD users are familiar with a source tree compile
> with autotools.

Really?  In 2009?  Do you have a source or at least some anecdotes to
back up that idea?

If you are correct, why was it valuable to get this software packaged?
If that is really the standard conventional way today's Linux users
expect to receive and install software, then packaging it for them in
distro-specific ways is clearly a waste of my time!

About 15 years ago, I would have agreed that most Linux users knew how
to use autotools and gcc and friends.  Maybe 10 years ago that was still
true, although it was definitely a declining fraction of the userbase,
even then.  I'm not at all sure the same is true today.  How much time
have you spent on the Freenode IRC support channels such as #ubuntu or
##linux or even #debian recently?  I assure you, the vast majority of
questions being asked are not coming from users comfortable with the
command line and with compiling their application software from source code!

> When a Linux or BSD user searches for software on the Internet, finds
> a home page, and sees a "Download" link they're very likely to be
> looking for an option that ends in a .tar.gz or .tar.bz2 so they can
> pull the source, compile, install and be on their way.  This is
> native and natural ...

I submit that it is no longer natural at all.  In today's Linux world,
for end users, application software is packaged and signed and tested
before being allowed into a repository, and there are very few of these
for a given Linux distribution.  The natural way to search for software
is therefore with your package manager, which is often a GUI tool
(Synaptic for example).

Newcomers quickly find that you *don't* go around searching the Internet
for Linux software in random places, because (unlike Windows) installing
it when you find it there is often "too hard".  Instead, Linux users
will often only use what is already packaged for their specific Linux
variant, and which is easily available for installation in a pretty GUI
tool.  Some will even wipe their hard drive and reinstall from scratch
to use a different Linux distribution *just* to get some particular
piece of software that one distro packages and another does not!

In Ubuntu, the default way to search for and then install software is to
click on a menu item labelled "Add/Remove...".  It brings up a
(deliberately simplified!) graphical package manager.  I suggest that
this is a clear sign that today's Linux distros do not expect their
users to be experienced in downloading and compiling tarballs at a
command line in order to install software :)

I really do not think one should expect any autotools and compiler
knowledge at all in the average Linux user.  Not any more.  Those days
are over.

> It is native and natural for a Windows user to look for a package
> that ends in .msi or .exe and download and install that.  This is how
> software is expected in Windows.

Indeed.  They lack a common package manager, so they have to search the
entire Internet for individual (binary) packages.

The direct equivalent in Linux is a binary .deb or a .rpm for ones own
distribution (most commonly found in the repos for ones own distribution
rather than elsewhere, to avoid dependency issues or trojans).  This is
how software is expected in Linux, in 2009.

Indeed, so prevalent is this approach that even providing .debs for
download in PPAs is considered by some to be for the "expert" few only,
and we find we need to provide a way to enable our team PPA that
completely avoids the command line, so that the PPA contents will be
useful to many users!

And, as I said earlier, Crosswire currently directly provides the former
(compiled binaries for Windows) but not the latter (compiled binaries
for Linux).  So which is the "poor cousin"? :)

> On another hand, one could also point out that autotools is native to
> the SWORD library, is regularly updated when file names, directory
> structures and the like change.  Thus, at any given point, a user
> could just pull the SVN tree and have a very high probability of
> things "just working."

Autotools is not Linux-specific.

> The Windows build files are maintained manually -- nearly every time
> I try to build from SVN on Windows (which is every 4-5 months, so not
> very regularly) thus far, I have had to edit the file list, or find
> compiler directives and defines, etc that need to be tweaked because
> of the manual system which does take a "poor cousin" seat all too
> often.

Really?  For SWORD itself?  Not strange proprietary "project files", not
tweaks needed to suit one version of one specific commercial compiler,
or a specific IDE -- just the usual standard autotools/Makefile/GCC
approach, that is the same on all the other operating systems supported?
 It is 4-5 months since SWORD 1.6.0 was released, so can you provide an
example of what in the SWORD 1.6.0 tarball had to be changed to permit
Windows compilation of SWORD with autotools/GCC?

> There are also file system paths on Windows which had not been
> tested, then were found to mishandle unicode.

Sure, but (to the limited extent that I understand that issue) that's
not the SWORD developers making poor cousins our of Windows users --
that's Windows containing bugs :)  I strongly suspect that the
equivalent code paths were not really all that well tested by the SWORD
developers on Linux either -- it is just that in Linux they worked even
when using non-USASCII characters in file and directory names, whereas
in Windows they did not.

> Looking for those perspectives, it certainly does appear to some
> viewers that Windows is a "poor cousin" in the scheme of things.

Given what is available right now on the CrossWire site, and nowhere
else, I see no basis for that.  The Crosswire site has source code for
all, has SWORD modules for all, and has Windows-specific binaries and at
least one significant Windows-specific project.  In contrast, it has no
Linux-specific binaries and no Linux-specific projects.

It's sad that independent Windows developers can't fix their core OS
libraries unicode issues, as independent Linux developers could if such
bugs existed in Linux... but that dependence on Microsoft for the core
OS is a choice that gets made when you choose that OS.  For some people
the benefits must outweigh the disadvantages.  At this point it might be
fun to suggest that Microsoft makes its own users (or its own
independent developers, and so indirectly its users) into "poor cousins"
by restricting access to source code ... :) :)

> For better or worse, Windows DOES garner less attention than the
> library itself, and probably less attention than Linux -- because
> there are dedicated teams working on Xiphos, BibleTime and the rest,
> while the BibleCS work is done almost exclusively by people who are
> also concentrating on the whole library.

So perhaps, just as some months back there was a call on a relevant
mailing list for help packaging SWORD for Ubuntu, to which I responded,
there is now a perceived need for a similar request for help packaging
SWORD for Windows, so relieving any pressure on the Crosswire devs to do
that kind of work themselves?  I don't know what mailing lists would be
appropriate for such a request, but if it worked for Ubuntu, perhaps it
will work for Windows too?

> It's more the fact that CrossWire clearly goes all the way for its
> Linux users, but the efforts on Windows do seem to lag behind,

But it *doesn't* go all the way for Linux... mentioning packaging SWORD
modules as .debs so we can truly integrate with the existing packaging
mechanism gets me... a lot of feedback, shall we say!  Suggesting .debs
and .rpms could be provided from crosswire.org itself does not seem to
be well received overall.  Crosswire could be creating nightly builds of
SWORD SVN and distributing the resulting .debs and .rpms for a few major
Linux distros.  That would be nice to see, a convenience roughly
equivalent to providing binary builds for Windows users.  But it isn't
happening... and so on and so forth.

[Aside: One obvious use of my .bat file based Windows development setup,
if it ever gets to the point where it reliably compiles and links SWORD,
would be to automate the creation of a binary Windows SWORD library
installer, and then run in nightly from svn, so the "latest" code would
be available as a nicely packaged .msi file to all who need it in the
world of Windows, but who lack the means or desire to compile it for
themselves.]

SWORD is at its heart a code library.  As such, it seems clear to me
that its primary expected users are programmers -- people who will write
programs that use that SWORD library code.  Whether those programmers
are Windows or Mac OS X or Linux programmers is not the point; the point
is that the expected primary software output of Crosswire is a product
suitable for use by programmers.

Taking SWORD beyond that, packaging it to be more suitable for use by
end users i.e. by non-programmers, is a different project entirely, and
one that others will need to choose to run with.

Xiphos programmers have worked to package SWORD with their Windows
application, so that Windows users do not need to be concerned with
downloading and installing a separate library.  Great idea (I wish there
were a way to package SWORD for Windows that is more independent of
which application will be used "on top of" SWORD, though)!

If we want to see more of that kind of work, adding polish and ease of
SWORD installation for Windows end users, cool... but to expect the
SWORD developers to be the ones to do it seems to me to be expecting a
lot.  If, as you suggest, SWORD devs are mostly Linux programmers, it
would probably be more natural for them to package their library for
Fedora/Debian/Ubuntu/Mandriva/etc. than for them to package it for
Windows.  They do not even attempt the first; why would anyone expect
that they do the second?  Both are tasks left for others to do, building
on the work of the SWORD team.  Which, given the size of the team, is a
very valid way to divide up the total necessary work :)

> This could just be my experience, but I can count on a single hand the
> number of PC power users I know who are comfortable with virtualization
> without being programmers.

All I can say is, I know people for whom typing is slow and hard, who
much prefer GUIs and mice and clicking their way around... who use
virtualization.  It is very possible to download and install VirtualBox
OSE and get some friendly Linux distro of your choice up and running
inside it without seeing a command line at all, never mind being a
programmer :)

> If we're going to offer applications and utilities for an operating
> system, it makes sense to offer them in the format most comfortable and
> native to its users.

Sure.  I wasn't intending to propose virtualization as a permanent
replacement for a lack of up to date packaged Windows binaries!  But if
right now there is some issue with that, such as a lack of a team
packaging the latest output of Crosswire for the Windows environment,
then, as a stopgap measure, running SWORD-based apps inside a window on
Windows (that happens to be a Linux VM) is one way to make forward
progress.  Without forcing Windows users to learn the Linux command
line, or even the Windows command line for that matter.

> Saying to them, "Oh, just get virtualization software and run Linux"
> or "Go learn how to use a compiler and figure out how autotools will
> work on Windows, then build it yourself" does not increase our
> likelihood of acceptance with a market of people for whom that is 
> neither the norm, nor a comfortable stretch.

We don't expect Linux end users to use autotools or a compiler.  We
don't expect Windows end users to do that either.  The platforms are
100% identical in that regard.  Windows is neither a poor cousin nor a
rich uncle in that regard.

We do tend to expect developers on either platform to be developers who
are unafraid of the command line.  That's not unreasonable on any
cross-platform project, really... and if someone wants to create a GUI
wrapper for the utilities, or some Eclipse project stuff so that
building SWORD inside a huge GUI IDE like that (on Windows or on Linux
-- Eclipse runs on both) would become relatively simple ... OK, both of
those are nice (OS-independent, cross-platform!) projects which someone
who likes GUIs or who likes IDEs can take on if they choose.

Crosswire in essence outputs a code library (and a few command line
utilities).  It hosts a repository of SWORD modules that the code
library can use.  Others then take that output, and use it to build
software for end users (or any OS) who do not think of a library as
being a set of files that contains code, but as a building that contains
books!

At most, we can say that current packaging efforts for SWORD on Windows
lag the recent efforts and progress being made in the Debian/Ubuntu
arena; just a year ago that was far from the case, though -- and even
now, the current release of Ubuntu comes with an incredibly ancient
version of SWORD (this will change in a few short weeks when Karmic is
released)!

Those packaging efforts for Debian/Ubuntu are outside of Crosswire.
Comparable efforts in the Windows world could and perhaps should be
undertaken in a similar manner -- outside of Crosswire itself.

> I know that this is largely just a perception issue.

Looking at the output of Crosswire, and not the output of other related
projects, I don't really see where that perception comes from (unless
you make assumptions that all Linux users are developers).  The primary
software output of Crosswire is a set of source code files, which are
compilable on Linux, OS X, *BSD and Windows, by developers -- asking end
users to do that is of course expecting too much, no matter the OS platform.

> But to the casual user strolling through the website who sees version
> 1.6.0 available for Linux but only 1.5.11 available for Windows, it's
> easy to see how they might be confused.

Well... maybe so, but surely SWORD, as released by Crosswire, is clearly
not intended for a casual user strolling by, on any platform.  It's a
software code library.  How many C++ code libraries do you know of that
are intended for "the casual user strolling through the website"?  A
"casual user" of any OS is not going to be able to do anything useful
with SWORD 1.6.0 as released (a pile of C++ source code) anyway.

Oh, hmm, the Windows part of the site doesn't point to the source code?
That's probably a web site bug, since the SWORD source code is
definitely available for all OSes.  Another probable bug is having
http://www.crosswire.org/sword/software/ still refer to GnomeSword under
"Linux Software", and not mention that Xiphos is now a viable option for
Windows too, I suspect.  Likewise BibleTime should probably say (Qt)
rather than (KDE) these days.  Again though, none of those things appear
to me to be loaded pro-Linux or contra-Windows, they are just small web
site issues that will no doubt be corrected/updated, in time.

Jonathan