Democratization, Writing and Writing Code
Posted 21 Nov 2006 at 20:49 UTC by mako
Advocates of free and open source software, myself included, like to
talk about the "democratizing"
effect of free software. Others, especially non-programmers, are
quick to point out that the only technical people can take advantage of
half of the enumerated
freedoms in FOSS. The freedoms to modify and collaborate mean little
if you don't know to program. Over time, I have come to the conclusion
that the only good solution to this problem -- and one that I was
initially quite opposed to -- is to teach everyone to program.
In considering this position, the processes of reading and writing
provide a useful analogy when considering the processes of using and
creating computer software. Additionally, the analogy provides an
powerful justification for the fact that FOSS programmers produce a
disproportionately large amount of software that is primarily of
interest to FOSS programmers.
Imagine a world where students are taught to read but only a select
few are taught to write. The result is an undemocratic and ultimately
unjust arrangement in which access to what is perhaps the most important
tool of expression is limited to a narrow sector of society. The effect
of such a pedagogical split would be to create two groups along stark
and impenetrable lines and to aggravate existing power imbalances.
Members of this society would be either part of a disempowered group
that consumes ideas and expressions or part of an empowered group that
produces them. While similar divisions exist today, it is the uneven
distribution of technological knowledge, in this case the technology of
writing, that makes it technically impossible for the disempowered
consumers to transcend their roles. It is this intentional and
inflexible disparity in access to communication technology that makes
this hypothetical society dystopian and undemocratic.
But as scripts are merely communications technologies, it's
unsurprising to find the possibilities for similar double-standards in
the context of other technologies. It is clearly present in the case of
software. For a growing number of people, myself included, software is
as fundamental to our communication as writing is. For us, software sets
the terms and the limits of what we can say, who we can say it to, and
how we can say it. Of course, the power to set each of these limits is
one reserved for those who (1) have access to the tools necessary to
modify their software (most importantly, the source code) and (2) have
the necessary skills and knowledge to take advantage of this access to
change their technological environment. FOSS is a powerful force in the
democratization of technologies because it addresses the first half of
this problem. However, astute critics have been quick, and correct, to
point out that free software alone does nothing to address the second
To argue for FOSS a democratizing process, free software must be
deployed in concert with a programming education for all users of
software. In no uncertain terms, if one believes that society's
communication is largely mediated by software and if one believes that
communicators should be able to define the terms on which they
communicate, all users of computer software must learn to
program. The analogy between reading and writing described earlier
provides a powerful justification for this position. The alternative to
universal programming knowledge, the analogy implies, is similar to the
inherently unjust world where certain readers cannot write.
One potential response is that people have different skills and
abilities and that it is unfair to expect everyone to become a
programmer. Similarly, I believe, it would be unfair to expect everyone
who learns to write to become a published or professional author. But
nobody demands such a thing of writers in in the context of campaigns
for universal literacy. Learning to write, like learning to program, is
about getting the tools necessary to transcend one's consumer role and
not transcendence itself. It is about democratic distribution of
access and not distributing expertise evenly. Through
distribution of skills of writing or of programming, there is a such a
distribution of access and of power.
Finally, a common critique of free and open source software argues
that FOSS is flawed in that it produces a disproportionately large
amount of software that is primarily useful or interesting to
programmers. The preponderance of FOSS debuggers, compilers, editors and
libraries seems to support the facts behind this assertion. Yet, while
many in the FOSS community recognize this as an indictment and use it as
a call to arms, the reading/writing analogy provides a more optimistic
justification. A trip to most books stores and libraries reveals a
disproportionately large number of books on writing. Of course, it
should come as no surprise that writers like writing about writing and
do it more often than writing about other topics that might be more
popular in the general population. There are probably more people that
prefer professional wrestling or pornography to writing than the
converse, but there are more books on books than either of these topics.
This distribution represents a bias, a real one, but history shows that
it does not signify a fatal flaw in the process of writing or the
instituation of universal education. The analogous bias in FOSS is
similarly real, but perhaps, like writing, is a bias that simply comes
with the territory.
 This is
not to say, however, that FOSS developers have not worked for the
distribution of these skills. Personally, I have created a software freedom
curriculum as attempt to discuss how we might teach kids using free
software that their software environment is malleable and to give them
the skill to do exactly this. The second goal is also the reason that I
am interested in technologies like Squeak, Scratch and Logo
that make learning the complex concepts behind programming easier. It is
a reason that I have advocated a single extension language across a
desktop and operating system so that someone can learn one language and
then take control of their entire computing environment.
'the priesthood', posted 21 Nov 2006 at 22:06 UTC by lkcl »
your article contains some very good points - ones that i have been making for some time.
i have often had some incredibly arrogant replies to my posts to LKML, and one very special one, which i will always treasure, which quite blatantly said, after i explained that i felt quite honoured that one of the more experienced LKML developers was taking the time to talk on-list with me about a particular topic, that 'oh no, the only reason i'm talking to you is to be able to demonstrate, on-list, quite how stupid you and your points are, and i am waiting for you to fail'.
i should clarify: when i say 'arrogant' (which means 'ignorant' and 'egoistical') i am in no way saying that the LKML people are _technically_ arrogant. there is absolutely no question of their _technical_ ability.
however, as has been demonstrated repeatedly, the ability and expertise in a technical field does not necessarily translate into either ability or expertise to make any _other_ decisions - in particular, strategic ones. decisions which, if the people making them got off their technical high horse, would open up an entire new area (probably quite unknown or even anathemic to them) and would allow an entire previously closed-off area of exploration, users, developers etc. to 'join in'.
'closed' _doesn't_ just have to be about source code, when simply keeping a [non-mainline-] patch up-to-date [with mainline source] takes _hours_ of your time, and you spend more time updating your patches than you do actually developing code. knowing this sort of thing can _really_ put non-mainline-developers off from even _trying_ to contribute, especially when you know that, on your own, you cannot achieve more than the mainline group can.
i gave a talk at UKUUG in bristol, 2006, where i pointed out that our abilities should be used (and it was quite a long list) to reach the most people that we can, to help those people for the longest time that we can, using the most of our brains that we can, with the least amount of our actual time spent.
in other words, i was doing an advanced version of the parable of the talents - for techies.
alasdair picked me for the first talk on sunday morning (argh) which was good cos my talk was non-techie.
the audience was _very_ helpful.
now - what _really_ pisses me off is this hearing about debian wars and things like 'well if you don't have a thick skin, get off the lists'. and the arrogance of the xfree86 key developer. and the arrogance of the so-called samba team leaders in 2000 (that was truly technical arrogance as well as strategic-ignorant arrogance as i knew a hell of a lot more about nt domains than they did).
i could quote you countless more examples, and all of them hurt free software development and some of them have cost businesses world-wide, over the years, hundreds of millions of dollars in license fees to microsoft and other proprietary companies.
last, but not least: it is worth noting that what you say is _exactly_ why the OLPC project is to contain a set of development tools.
And I don't want to know. I have no interest in cars or how they
function, except for the minimal knowledge I need to use them as a tool
for bringing me from one point to another. I much prefer to spend my
time improving my skills in areas that hold my interest, such as
programming. Thus I use the money I earn from my programming skill to
pay a mechanic for his skills with cars.
I feel pretty sure my car mechanic has no interest in learning to
program, he seems to for some reason find cars a much more interesting
subject matter than computers.
Now, the freedom I want as a mere user of cars is the ability to go to
any mechanic for repairs and service, rather than only to the original
manufacturer of the car. This ensures that there is a competition in
prices, and that I'm not at the mercy of a monopoly.
Free software offers the same benefits to it users. Instead of relying
solely on the company that sold them the software, they can get any
programmer with the necessary skills to make repairs and improvements to
the software. Of course, the original developers have an advantage in
that they know the software the best, and can therefore usually offer
the best prices for service. But the theoretical ability to choose
another service provider keeps them honest, and protects you if their
PHB gets a "vision" for the project that does not include your needs.
I know some people feel that all people should be "renaissance men", and
be skilled in each and every form of art. I feel the same about those,
as I feel about anyone else with strong opinions about how others
should live their lifes.
Not quite, posted 25 Nov 2006 at 17:37 UTC by joolean »
No offense, guys, but I think these first two comments are missing the point of the piece -- the "Linux programmers are insular / arrogant" and "Joe Sixpack doesn't want to learn C" are topics that've already been addressed at length and for years in the FOSS community.
Rather, I think what Ben's getting at is that there's this artificial divide between "computer users" and "computer programmers," and that the reason for this is partially due to the way we educate people who use computers, but also has a lot to do with the software development tools that are available -- that's the novel idea here.
Imagine, abraham, if your car's engine, steering control, gas tank, etc., were observable / controllable via a high-level scripting language (or, say, a grammar of voice commands) that might not present the same kind of interface to you as the one your mechanic would have, but would give you control, as deep as you chose to pursue it, over every useful aspect of the vehicle. It would probably change the way you interacted with your car, making you a more efficient driver and "consumer" of the automobile. That wouldn't make you a mechanic per se, but you'd be a guy who was really "using" his car instead of just interacting with it in a very prescribed way.
Re: Not quite, posted 25 Nov 2006 at 19:37 UTC by bi »
But at the end of the day, a scripting language isn't going to "give you
control, as deep as you chose to pursue it". Squeak isn't assembly language,
and will never be. Teaching someone Squeak may give him somewhat more
control, but it won't give him total control.
... by mistake, you have hit on something that's a very useful analogy. black-box modules in cars are $EUR 700 to replace. 'oh, we can't fix your car, sir, it's a problem with the on-board computer'.
the adapters to talk to these on-board computers cost about $EUR 40 each.
the software costs about $EUR 3,000 with software-updates required every year as new makes and models of vehicles come out.
a law in the US was passed requiring that the same adapter be used across all cars.
the manufacturers responded by then changing the communications protocols to access the onboard computer _over_ the (now identical) adapter.
someone was commissioned to write some software, according to the standards, to communicate over the serial link, as part of an independent study. he released that software under the GPL, and was then sued by the very commission that sub-contracted him to write the software. he won - and then donated the money he won _back_ to the commission, as it is a non-profit organisation.
(you can probably find a better and less garbled version of that story, online, if you look).
the point is: control of software and standards is being used as a weapon to keep people ignorant. the _control_ of software and standards is being used as a weapon, to keep people ignorant.
it was a lot easier when computers were simpler, and there was less 'pap'. i remember typing in assembly code for a game (that actually worked). i remember _buying_ my first ever software - a BASIC compiler for the zx spectrum, that only coped with integers.
so, if a nice shiny oversimplistic scripting language makes an introduction _any_ introduction to computing, then GREAT.
but - yes: it takes a particular kind of mind to cope with computing - with or without the 'help' of a simple scripting language: one that is capable of making independent inference jumps. "Do These Things And The Results Shall Appear".
most people, when presented with a simple list of instructions to follow, simply CANNOT FOLLOW THE INSTRUCTIONS.
they don't understand that the instructions must be followed to the letter.
they don't understand that they must be followed in sequence.
the concept of a keyboard is alien to them.
even when you tell them exactly what letters to press, they will not be able to infer, from the text appearing on the screen, what they are doing. they think that because they have typed, everything must somehow magically appear in the middle, right and nice and obvious before their eyes, and only that.
and the 'nice pretty windowey whizzey' stuff actually detracts from that.
text appearing at the _bottom_ of the box, in the command-prompt, is an alien concept.
i remember when i was ten, working on a commodore pet 3032: 32k of RAM, a 1mhz 6502 processor with a 40 x 25 SEVEN inch B&W screen.
i was SCARED! it was so... intensely.... sparse.
now you put windows in front of people, and they don't even have to _touch_ it for it to 'go wrong' and for other people, total strangers, to steal their credit card details and shove spam up their backsides.
is it _any_ surprise that ordinary people, whose daily diet comprises 3 to 5 hours of TV per day and who cannot concentrate on following instructions to the letter, cannot cope with programming?
Disagree, posted 28 Nov 2006 at 20:34 UTC by joolean »
most people, when presented with a simple list of instructions to follow, simply CANNOT FOLLOW THE INSTRUCTIONS.
You're being a bit cynical. If this were true, nobody would get anything done, ever. And I don't know if I quite follow how that car "firmware" analogy applies, except insofar as standards keep companies competitive and make everybody's lives easier, particular software developers'.
At the risk of sounding pedantic / obtuse, we're not in need of a tool that gives people an "introduction" to computing, we need something that does away with the divide I mentioned before, and I think such a solution will be linguistically structured, but that inclination probably comes from too much Star Trek and too little (i.e., zero) time learning about HCI.
bi: Well, let's say... as fine-grained a level of control as you get over your system via a good libc implementation.
dan, my brother, took the unusual step to teach the kids about computers by giving the class the job of setting up and maintaining its web site services. they are using debian, apache, php etc.
95% of the kids did not understand how to use google to find instructions, and they also could not follow those instructions once they had been found.
out of a class of twenty, only about three of them actually 'got it', and it is these kids that dan will entrust with maintaining the site for the rest of the students, under his supervision.
Mild disagreement, posted 30 Nov 2006 at 21:21 UTC by ncm »
Luke, I still don't agree with your definition of "arrogant". It is
possible to be both particularly ignorant and arrogant (witness the current
U.S. president), but arrogance is overwhelmingly more commonly seen
among the heavily-educated. There's a category error lurking, too:
ignorance, like ego, is a condition of a person, but arrogance is a
Anyway, it is impossible for a
mere human not to be ignorant, given the tiny fraction each may master
of what is known, even neglecting the overwhelmingly greater amount that
is not known yet, and the appalling fraction of what each believes which
is, in fact, false. Certainly most people fail to recognize how little
they understand of
the universe. Still, some people do recognize it, yet behave
arrogantly. What is certainly more characteristic of people
being arrogant is that they don't listen well, most typically because
they feel they have not time for it, and don't believe (certain) others
offer much to learn from.
About teaching programming... if I had a choice about what
"everybody" would learn, I would easily choose to teach fundamental
processes of science and logic before programming. Programming is one
application of such processes, and thus offers frequent practice in
applying them, but other activities may exercise them equally well.
Very well put, ncm. Teaching programming is like
teaching a spoken language by example only. Only when knowing the
grammatical rules correct new constructs of increased complexity can be
Many, many people beyond professional programmers are already exposed to or have learned programming fundamentals. The spreadsheet was one of the first killer apps while some modern word processors require specialist assistance for initial document setup. Every U.S. accountant surely programs his/his spreadsheet occasionally and every U.S. secretrary or administrative assistant or secretary has surely been exposed to WordPerfect, Word, or other hidden command or formatting codes which require "programming".
Part of the reason that programming skills are not as pandemic as some appear to wish (universal by mandate seems a bit totalitarian to me as well) is that while computers are becoming ever more pervasive many people can still avoid them and wisely do so. If one did not need a car would it not be wise to avoid insurance, licensing, maintenance, and other unanticipated expenses or aggravation?
Commercial propaganda aside I still get along quite nicely with no cell phone, no handheld internet access, no user trip computer (yes there are computers/chips in my automobile and no I cannot program them), etc. etc.
It seems to me that computer programming is already one of the most viral disciplines of human knowledge spreading almost by itself, far, and wide. So far however, this is due to usefulness, not ideology.
One problem that exists is the language of choice for applications programmers seems to change every three months in every other field of human endeaver. This means my limited experience programming HP41CVs in assembly, minicomputers in assembly and Fortran, brief foray towards AI and Lisp, spreadsheets and word processors in proprietary languages, desktops in C, games in Director and Flash, and lately learning Java is probably totally useless in my next project or job; regardless of whatever focus may or may not arrive with the preliminary project requirements.
When forcing people to learn how to write at a rudimentary level; public schools generally stick to one alphabet and one language and declare victory when minimum skills are demonstrated successfully. So far I can still buy books in English and turn in timesheets and written work reports in language I learned thirty years ago in Junior High.
What computer language would you propose as a minimum common denominator that could be taught to everybody in public high schools for use in mandatory programming proficiency training?
BTW I am aware that open source software may change much of the periodic planned obsolescence cited above .... assuming one can buy or build hardware compatible with web accessible free software. Also assuming one can buy web access in a compatible format from U.S. "free" markets.