Let principles of technical merit lead advocacy
Posted 25 Jul 2002 at 20:18 UTC by Alleluia 
Some of you already know this; others may find a few
points worth noting. There is a useful purpose for
open source advocacy. However, it must be used
carefully, because it can divide your audience between
people who love your message and people who hate it.
While this in itself is true of any message, the
shallow sort of love earned by advocacy alone is
nothing like the sort of love which comes because of
true merit.
Advocacy must be rooted in a deep background of
technical merit; in short, it must be the tip of the
iceberg. Otherwise, you'll have a three-fold effect,
no part of which is desireable:
1. The people who already support open source concepts
will gain no further depth from your message. To them,
your message is comforting, but a distraction from
actual depth, which they'll have to find elsewhere.
2. The people who already have an entrenched opinion
against open source development for whatever reason,
will _never_ be convinced by advocacy alone. Instead,
they'll see advocacy as spin-doctoring, and will spend
their energies finding your flaws.
3. The people who are not yet decided will make their
decision based on a shallow advocacy. As soon as they
encounter more merit supporting closed source, these
people will switch allegiance. A great loss, because
they'll feel 'cheated,' and be harder to convince back
again.
Thus we can see that the most effective free software
advocacy is that which carries a great amount of
technical depth. For example, while all of the
information revealed in the letter from Peruvian
legislator was commonly available before Dr.
Villanueva wrote the letter, it had not yet all been
used so effectively in one place as in that letter.
The letter was a well-poised conjunction of technical
knowledge, unassuming clarity in language, and a
political situation which gave a compelling context of
passion to the whole exchange.
We all know that the best advocates of open source
development are the people who actually develop
quality code. However, there is a place for evangelism
which is performed by people who specialize in that
task. Thus this brief article, which discusses some of
the principles of advocacy of the sort refraining from
alienating people.
Advocacy which clearly rests in the language of
pragmatic merit, rather than in the language of "good
vs. bad" struggles continually to keep the discussion
clean, like code should be, so that more information
can be passed back and forth. Why the struggle?
Because as soon as a conversation resorts to exalting
one solution over another, all the strengths of the
opposing solution must be ignored because they are
seen to represent the opposition. It's hard to harvest
from a garden where you've just proclaimed all the
fruit bad.
This means that fewer strengths can be incorporated
into the overall discussion since they are being
isolated into an artificial war against each other.
This is a real weakness of 'categorical thinking,'
where by categorizing information, we can communicate
whole blocks of information very quickly, but we also
lose track of some of the valuable information which
crosses categories.
For example, by saying that a particular vender's
engineers are all stupid (categorical thinking), you
leave no room in the conversation for an exception, a
person who happens to be brilliant, yet works for that
vendor. He is restrained by your comment into a
defensive position, kind of like the old question
"Have you stopped getting drunk every night?" which is
hard to answer if the hearer never gets drunk, but
everyone assumes by the question that he does...
That's the kind of question which sounds foolish when
there's two people in the conversation, but when
there is an audience, it can provoke a mob mentality;
best to stay clear of such provocative language,
if you intend to learn or teach.
If the conversation stays in the realm of technical
merit, based upon very practical standards of
feasibility, then people who compete directly are
still able to learn from each other in a manner which
protects their hidden interests. All that it takes is
a keen ear.
Thus, if we are to move forward gracefully, we must
become more comfortable speaking in principle-based
terminology, resorting to examples only when
necessary, and always conditioning them with a preface
that shows we mean them as examples of principles, not
as reasons to love or hate. Let the love derive from
the elegant structure of the OS, not from its
advocacy, and the depth will bear fruit.
In this nascent information war, the single greatest
strength our opponent carries is to cause us to
emulate him. Once we begin selling more than we have
produced, we have become the enemy, and someone else
will have to take up the standard.
the enemy?, posted 26 Jul 2002 at 23:53 UTC by dalinian »
(Journeyer)
I might be misunderstanding your idea, but isn't this "technical merit"
policy similar to telling kids not to steal candy because if they don't,
they don't get punished? Maybe it's just that you think that all the advocacy should be directed towards companies, and I don't. But if I understand you correctly, I have two points.
First, you don't take into account that there is something wrong in
using proprietary software. Second, even thought appealing to technical
merit may be more effective, its effects may be only temporary. When the
proprietary competition catches up (and it quite possibly can), the
argument loses its power.
Also, what's interesting is the war metaphor you use. To me, it doesn't seem like there is a war going on, or if there is, it's a cold war. Proprietary software cannot kill free software as long as there are people that care about software freedom. Companies can't be enemies of software freedom, but they can be too conservative. They can talk all they want how e.g. GPL is against the American way, but that's just rhetoric. If a system is wrong and fundamentally flawed, empty rhetoric doesn't help one bit.
Maybe we need to convince the people first. The companies will follow soon after. But convincing people is a bigger deal than just mentioning all the technical merits. rms's approach might not be so bad after all, but we need to be a bit less preachy about it. Being right is one thing and being convincing is another.
Which enemy.., posted 27 Jul 2002 at 01:56 UTC by timcw »
(Apprentice)
are you referring to? What I don't understand is why free
software must be advocated. Can't software stand on its on? Does it
have to come packaged with ideals and certain value systems? I
understand the need for GPL/BSD, but I'm not sure about GNU.
Let's imagine that tomorrow all software magically becomes open
source, as defined by the GPL and GNU. Now what? How does software get
maintained and/or developed? Popular, "sexy," software is simple to
find developers for. What about the less popular, corporateware? Stuff
that is only used in specifc fields/markets/etc. I think a popular
belief is the software will be maintained by corporations paying coders
to work on it, and releasing the results under the open source license.
I don't buy this argument. When there are two businesses in
competition, one of them has a free ride. But, then, would that
software even matter if it was free software (and downloadable)
anyhow? No sense in preaching to these corporations, which use mostly
internally developed software. What about Windows, Lotus, etc.
software? Would it be maintained? Who would even dare take the task of
maintaining something such as Windows? Does it truely matter
that all source code is available? IIRC, RMS had a printer/printer
driver that caused him trouble, which is somehow tied to him starting
GNU. If RMS had the source for that printer software, would he have
been able to fix it anyhow? What about in the future, when software
becomes even more tied to remote software? In this case, you can't fix
it even when you have the source. One good example is hosting
providers. Say there is an exploit in Apache. You have the Apache
source, but you are dependent upon your hosting provider to get moving.
Over the years the term "advocacy" seems to have moved from "getting the
public aware of what free software is" to mean "pressuring the public
into free software." I, personally, do not like this latter stance. I believe that proprietary can live with free software. It has been doing so for a long long time now. Free software has its merits, as does writing proprietary software to put food on the table. Combine the two in a magical way and we have our software utopia, otherwise they must co-exist.
dalinian:
Paying for proprietary software is not intrinsically wrong. If a group of
people have put in their time and energy into producing a piece of quality
software, is it not only fair that these people are rewarded for their
efforts? (Of course, there is also the famous company which reportedly just
scobs off existing software, adds some crufty glue, and sells everything at
exorbitant prices.)
And while the effects of mentioning technical merit may be temporary, the
effects of talking about software freedom are practically nonexistent. A
non-coder won't find much use for the right to read or modify source code
(so in effect "free software" = "freeware"). A coder will already know it's
important to be free to write code, and doesn't need much further
conversion.
I have seen many people who keep babbling about how free software is `good'.
Yet they are really slaves at heart, for they continually depend for others
to grant them their software `freedoms'. People who are truly free are those
who actively work to improve free software, regardless of whether
they talk about freedom or not.
Still, I wonder if talking about technical merits will work well outside the
organizational sphere. Organizations often have specific (or semi-specific)
IT requirements, and technical discussions do help here. But what about
advocacy for using free software for general personal computing, which often
has no clear requirements? Are there any useful methods for this? Is this
sort of advocacy worth pursuing?
tk:
Paying for proprietary software may not be wrong. But refusing to
make copies of it for your friends is wrong, I think. Yes, it
may be illegal, but it's hard to see what kind of ethical principle one
would violate by making copies of proprietary software. It does not even touch on issues about personal property, because intellectual property is not really property of any kind.
Also, software freedom may not be appreciated simply because people
don't know better. If most people really had a good idea about the
things what proprietary software companies do - and perhaps more importantly, what they have the potential to do - freedom would be
appreciated much more. Currently there isn't much transparency, because
the issue of software freedom isn't very popular in the media. I don't think it's impossible to change the situation.
And about the "slaves at heart" thing: if I understand you correctly, it seems that you base your argument on a misunderstanding of freedom. All freedom depends on others. All people can be kidnapped, for example, and that means anyone can lose her or his freedom. But there are mechanisms in place that make this danger in everyday life seem nonexistent: there is for example the police, and also many people watch out for each other, at least in the sense that criminals rarely want to do their crimes on daytime. In the software world, no such mechanisms exist, because people don't know about these issues. And that's something advocacy could change.
- I see restrictions on copying proprietary software as a hack to ensure
that software authors are rewarded for their work: it's not neat, but
there's no better way at the moment. In an ideal world, people will pay
for the writing rather than the distribution of a program,
and this cost will be somehow evenly distributed across all users of the
program. But a feasible way to implement such a payment scheme hasn't
been discovered, as far as I know.
- Do you seriously believe people will start scrambling for free software
if you tell them, for example, that Microsoft can easily snuck spyware
into their systems?
One of my peers once told me that, when you tell an average person that
Windows is full of security holes, and that he should perhaps switch to
some other OS, what he'll do is panic for a while -- then do nothing
about the situation. I asked, "Why?" The answer: "Because he feels
helpless."
And this is a problem. It doesn't matter whether someone is
helpless or not; what matters is that he feels helpless. The only
thing he `knows' is that he's being `forced' by the rest of the world to
use Windows, and there's nothing he can do about it.
This sort of `helplessness' appears even in free software advocates. (!)
I've met many advocate-wannabes who keep wishing that some third party
will magically come along, and help create the ultimate
free-software-friendly infrastructure / organize the next talk by some
open-source luminary / etc. "Why don't you do something yourself?" I
asked. And it's always "we're too busy" or "we don't have enough
resources" or "we don't have enough manpower". (What sort of advocacy is
this?)
And this is what I mean when I say some free software junkies are really
"slaves at heart".
Mouthing words of freedom is shallow
advocacy at best. To truly achieve a deep effect, one must root out the
helplessness that's in people's hearts. And I do believe that dwelling
on technical merits (including the technicalities of software
development models), and actively getting people to exercise
these merits, can help towards this.
helplessness, posted 27 Jul 2002 at 20:34 UTC by dalinian »
(Journeyer)
tk, it seems you are talking about many different kinds
of helplessness, and each of these requires its own answer.
First of all, there is the helpless Windows user who wants to switch
to a free system but for some reason doesn't do so. This kind of
helplessness is the result of having too little (or in some sense, too much) information. The
solution is not to talk about technical benefits, but to convince the
person that free software is a genuine alternative, that most people can
do the things they want to do with a computer completely without
proprietary software.
Second, there is the helplessness of the "lazy" developers. I don't
understand their attitude. We don't want people to start using free
software, if they can't get their work done with it. At some point, we will get to the point where they can. For example, the GNOME and KDE guys are doing good work, and we are getting better all the time.
I am also interested in the motives of the advocacy. Do we want free
software to "win" because our life as free software users would become
easier in the mainstream (more support from hardware companies etc.)? Or
is it because we genuinely believe that proprietary software users
suffer because they have to use proprietary software? Or do we have some
more abstract goal, like advancing the art of software development?
I believe that when the motives are more clear, the advocacy can be
rethought to some extent. Now it seems that most people (maybe including
me) are just obsessed with getting free desktop to everyone's desktop
without having a clear idea why that goal is worth anything. I'm not saying we don't have reasons. I'm saying that we have lots of reasons, but we don't really agree on which reasons are the most important ones, the ones we should emphasize.
Dalinian:
When Larry Wall finished Perl, the Practical Extraction and Report
Language, he was quite familiar with the limitations of advocacy. Since
he had created a new language, people expected him to create a new
newsgroup to advocate Perl, which he strongly resisted. He did _not_
want Perl to be dragged into an advocacy battle. Here is what he did
instead:
He and a handful of friends remained on the various C and Unix admin
lists which had inspired him to create Perl. Whenever they saw a
question whose solution could be implemented in Perl, they answered it
twice. First, they gave the "C" solution, or the "Unix shell" solution. Then they followed it with the much simpler Perl solution.
This had a trickle-up effect. Slowly people came to see that Perl was
an amazingly powerful script language which could do a lot of routine
tasks elegantly. It was never 'advertised.' Note the letter 'P' stands
for 'practical,' which perfectly describes Larry Wall's approach. The
rest is history. This is a perfect example of "advocacy resting firmly upon the foundation of technical merit."
It is my observation that TK perfectly understood the original intent
of the article, and spoke with clarity about the limitations of
advocating without actually enabling. He accurately described the
helplessness of the Windows user who hears about security holes in
Windows, but lacks an ability to migrate to Linux.
Your solution? "not to talk about technical benefits, but to convince
the person that free software is a genuine alternative." TK and I both
say "he needs more than that." You are basically proposing we "market,
market, market" Linux, without devoting ourselves to the technical
merits in a fundamental manner.
Please read again what TK was saying in his closing paragraph: To talk
about freedom without actually rooting out the helplessness in the
heart, is impotent. You say that we need to "convince the person that
free software is a genuine alternative." Well this can best be done by
demonstrating technical merit. One fine example is the number of movies
being produced on Linux server farms, another example is NASA
converting to MySQL, a third example is an entire operating system and
thousands of programs available at no cost. This is advocacy rooted in
technical merit.
What I mean, is advocacy that
speaks for itself, rather than needing a boost from a large
marketing department.
The proper way of advocating, is to enable a person WHILE advocating a
new solution. Simply advocating a new solution does nothing. Take a
look at .NET for an example of advocacy without technical merit. Take a
look at 9,000+ 'vaporware' projects at SourceForge, for a
similar same weakness within Open Source development. Not all of these will bear fruit.
As for searching motives, that only works if there is a separation
between technical merit and advocacy. There is no 'motive' to advocacy
when it rests on technical merit. In this form, advocacy is an
expression of quality, not a description of it.