Something's wrong in Free Software.
Supposedly I use a Free-as-in-Freedom desktop and operating system.
According to the Free Software Foundation, that means I have the "right to
use, study, copy, modify, and redistribute" all the software on my computer.
That's absolutely fantastic. As a professional programmer, it means I'm not
beholden to another company to make my living. As a user, it means that I am
not at the mercy of huge corporations, I don't have to pay a tax simply to
use my computer. Those rights, especially in combination, are empowering
because I can make my computer behave as
I need it to, not as some
cabal of programmers
think I need it to.
Or... am I?
For example, let's take this program I'm using right now, "drivel". As I
mentioned previously, I'm a professional programmer so I know my way around.
So, let's go through a checklist here. Use? Check. I'm using it. Study?
Let's see:
glyph@legion:/usr/bin% file drivel
drivel: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux
2.2.0, dynamically linked (uses shared libs), for GNU/Linux 2.2.0, stripped
Hmm... nope, looks like that's not really going to be easy to study in any
meaningful way. Let's see about the vaunted Source Code I keep hearing so
much about.
glyph@legion:~/Scratch/Build% apt-get source drivel
Reading package lists... Done
Building dependency tree... Done
Need to get 950kB of source archives.
Get: 1 http://archive.ubuntu.com dapper/universe drivel 2.0.2-5ubuntu1 (dsc) [883B]
Get: 2 http://archive.ubuntu.com dapper/universe drivel 2.0.2-5ubuntu1 (tar) [931kB]
Get: 3 http://archive.ubuntu.com dapper/universe drivel 2.0.2-5ubuntu1 (diff) [18.6kB]
Fetched 950kB in 4s (210kB/s)
dpkg-source: extracting drivel in drivel-2.0.2
dpkg-source: unpacking drivel_2.0.2.orig.tar.gz
dpkg-source: applying ./drivel_2.0.2-5ubuntu1.diff.gz
(...)
glyph@legion:~/Scratch/Build/drivel-2.0.2% ./configure --prefix ~/Scratch/drivel
configure: error: Library requirements (...) not met; consider adjusting the PKG
_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix
so pkg-config can find them.
Yeah, uh, I sure don't need that cabal of programmers to figure out what's
going on
here...
For the record, I know exactly what I need to do to fix this. I have, in
fact, built and modified this exact application on no fewer than five
previous occasions. However, unless I am already a Free Software expert, how
can I meaningfully "study" or "modify" this software without some kind of
documented way to progress from the software I see on my system, some way to
stumble my way towards an understanding of what's going on?
Also, this complexity really does explode to the point where it's a problem
even for experts. I am aware of how to get individual applications to build
and install into alternate locations for testing, but setting up a working
environment where I can meaningfully modify my operating system or desktop
is an exercise in futility. I know what's involved in setting up a gnome
development environment, vaguely, but I'm not sure how I would effectively
develop it without at least 2 computers, one for the debugger and one for
the main desktop. Surely something like a
rectangle with buttons on it
that start programs like Gnome Panel should not require a six month
training program and a 12-hour build process to get started on
modifying.
For a better example of how this might work, let's have a look at a program
with similar functionality to Drivel, "gnome-blog-poster". If I open up
/usr/bin/gnome-blog-poster, instead of seeing a mass of binary
crud, I see some words which vaguely resemble english. "from", "import",
"class", "self". I might not know what these words mean, but I can see one
phrase from the user interface: "Post Blog Entry". If I open up that file in
an editor, and modify the words between the quotes, then run the program
again... wow! The program is different now!
Knowing to look at a file in /usr/bin/ and launch a program like "gedit" on
it is hardly a seamless, intuitive experience (nor is editing source code)
but experiences like the one I just described really
are important.
Free software tools rarely realize the potential that they represent to
users; at best, it's just like Windows but cheap; at worst, it's like
Windows, but missing all the useful scripting tools like VBA.
Let me indulge myself for a moment in a metaphor. Supposedly this is to
clarify the point I'm trying to make clearer, but really I just love
metaphors.
Imagine if car manufacturers started welding car-hoods shut and legally
prohibiting opening them. This could be a serious problem; they could charge
drivers obscene rates for basic service like oil changes. In response - the
Open Hood movement; a massive undertaking, costing billions of hours of
volunteer labor, heroically laboring against the oppressive regime which
seeks to prevent regular folks from fixing their cars when they break, or
choosing their own mechanic.
After two decades of work and dozens of half-finished mopeds, go-karts and
engine parts, the first fully Open Hood car is released. To the automotive
industry's collective surprise, It's dramatically cheaper and gets better
gas mileage than the economy cars from each manufacturer.
However, beleaguered consumers are in for a surprise. Joe Average buys
himself an Open Hood car, and after a few thousand miles, he decides he's
really going to take advantage of the spirit of the movement which created
it, saving himself a few bucks in the process, and change his oil himself.
He gets his dipstick, and some motor oil, and expectantly pops open the hood
to find...
... a solid block of fused silicon.
Now, to an automotive engineer in this metaphorical universe (which has
metaphorical physics - a lot more fun and easier to get an A in than actual
physics) this may make perfect sense. In fact, it might be obvious.
"Avoiding moving parts improves aerodynamics", "exposing the driver to
complex parts wouldn't be user-friendly". Nevertheless, the movement's
promise is abandoned, and it instead simply a way to get cheaper cars, which
can still only be serviced at the dealer. It still decreases the cost of
service, because now
any licensed dealer can service a car, as long
as they have the $10M machine required to safely and temporarily crack the
fused shell around the engine.
Wasn't that trip into metaphor-land fun? If it was hard to follow, I'll
break it down.
C is the fused silicon of software. There are technical reasons to use it in
free software: it's fast, it's ubiquitous, it's UNIX's history, it's what
all the infrastructure is written in. And sure, in some places, like the
kernel, that makes sense. In today's real cars, there's a big difference
between changing your oil and actually trying to fully disassemble the
combustion engine. You need a
lot of tools for the latter.
The programs on a Linux system aren't themselves objects that you can study
and modify - you have to take the authors' word for it that the code you're
running is the same code they're running. Sure, you could use a distribution
like Gentoo, but that just moves the burden of the build process onto your
machine (and I would estimate 95% of the folks who use gentoo don't
understand the gibberish that scrolls by when they emerge something). The
final products are still opaque lumps with no obvious way to modify them;
the intermediary process is not designed to help the user. Finally, even if
it were, the multi-hour feedback loop necessary to see the impact of
anything modified in GNOME (and the absolutely disastrous impact if you get
anything
wrong) is going to be a turn-off.
When I was growing up, as young as 8 years old, I would change things around
on my computer just to see what happened. I modified arexx scripts, APL
programs, HyperCard stacks, batch files, anything I could get my hands on.
Then I ran them. Sometimes they exploded violently. Sometimes not.
It might be easy to dismiss this as simple nostalgia, but it's only
sometimes that these sorts of experiments lead to children learning to
program. Other times, they lead to more "serious" results like improvements
in office efficiency. Writing scripts with Visual Basic for Applications is
a very similar experience (although markedly less positive or fun) than
messing around with working HyperCard stacks.
Lots of people write programs to teach people how to program, and write
"scriptable" applications with absolutely no functionality implemented as
scripts. That might teach some people to program, or get some tasks
automated, but in general people can learn faster, and get things done more
effectively, by modifying full, working examples that are personally
relevant to them and that they can see some immediate feedback if they
modify.
I would like to close with two different points for two different
audiences.
Python developers, especially core python developers: remember CP4E? That
was a great dream. It saddens me that most of the work on Python these days
is adding syntax and libraries to the core language for web programmers.
Sure, that's a niche where it's useful today, but what about the future?
What about the desktop users of tomorrow? The only real way to make Python
into a language that's useful for everyone is to evangelize the hell out of
it so that everyone has at least one application they use on a daily basis
that's
written in python, and methodically hammered into consistent
and documented shape so that users can approach it at an odd angle. Novices
never show up in the orderly way you expect. Let's stop asking what the
people who are using Python today need: we are already using Python, clearly
we have what
we need. What about the people who aren't using
python? What do they need? How can we get Python to be the lingua franca of
end-user applications?
Free software C programmers - most especially desktop applications
programmers: holy crap, what's wrong with you. It's 2006, people, what are
you
doing. You will get your applications done in maybe 1/10 as
much time if you use a dynamic language. Don't make your applications
"scriptable", let your users get right into the guts and change whatever
they want. Your application will be fast enough, trust me. Rhythmbox, a
hulking monster of C++ code, is visibly sluggish and painful to use on my
computer; Quod Libet, a similar application written in Python, is snappy and
has a lot more features.
Fine, you hate whitespace, you don't use newlines in your code, you were
bitten by a snake as a small child, you hate British comedians, whatever. It
doesn't have to be Python. As long as there is an accepted convention in the
language for re-compiling at runtime and including the source with the
application, some users will figure it out.
(A brief aside to the Mono guys: even though compilation is a required step,
you're really close to this. Python compiles everything to bytecode before
executing it, after all. Can you just tweak the deployment conventions
somehow so you can easily run from a smattering of .cs files on the
filesystem, and package things that way?)
There are a ton of options available today. Use ruby, use lua, use tcl or
pike or csch or guile or clisp or javascript or perl or icon or sbcl or ...
you know, whatever. Look around and find something you like.
(But don't use PHP if you can avoid it.)
