Saturday, February 06, 2010

Anarchism and voluntary cooperation

An important element of anarchism is voluntary cooperation. As with "authority", I think it's useful to examine precisely what we mean or could rationally mean by this term.

It seems clear that under modern economic circumstances, there's a substantial material benefit to cooperation. No individual can create all the material stuff she needs to live a "good life". Other people made the house I live in; other people grow the food I eat, other people built the electric generators and other people operate them to provide the electricity I use, etc. Furthermore, regardless of the infrastructure, very few of the material things we can create today can be created by just one person working alone. We have created a world full of "irreducible" complexity (which we know can evolve through the use of scaffolding).

This is, of course, an observation about present day economic realities. There's nothing in the "deep structure" of reality that logically or ineluctably requires cooperation. It seems entirely plausible that we could develop the technological and social infrastructure that would make individuals truly self-sufficient, without requiring self-sufficient individuals to live in material poverty. We do not, however, have that level of technology today.

One of the biggest ideological differences between left-wing anarchists (libertarian socialists) and right-wing "anarchists" (Randians, anarcho-capitalists, big-ell Libertarians) is how they view economic or physical necessity. Right-wing anarchists see economic necessity as being inherently non-coercive; and if someone through some circumstances can leverage or employ economic necessity to interfere with the will of another individual, they are still not "coercing" that individual. Left-wing anarchists see economic necessity as genuinely coercive, at least in some sense.

I agree with the left-wing anarchists: economic necessity is coercive, and someone who leverages economic necessity is himself coercing others. "Work for me or starve" is just as coercive as, "Work for me or I'll kill you." I disagree with left-wing anarchists, though, in that I see economic coercion as being a part of present-day physical reality; economic coercion is not a purely social construction. Our social constructions do not establish but rather manage and distribute (or concentrate) coercion by economic necessity.

Just as we don't have true freedom of religion unless we have the freedom to adhere to no religion at all, we don't have voluntary cooperation unless we have the freedom to not cooperate at all. And we must have the freedom not just to survive, but to live a "good" life without any social cooperation at all. But noncooperation is simply not physically possible today, and without the physical possibility of noncooperation, we cannot have voluntary cooperation. We're just arguing over what kind of involuntary cooperation we want.

As I see it, the social constructions around economic necessity differentiate anarchists, "socialists" and communists. Anarchists seem to more-or-less want to wish away or socially-construct away economic necessity. You cannot, however, wish away reality; you have to work to change it. Socialists want to equitably distribute economic necessity (or, rather, equitably distribute capital, the means to respond to it). But capital, under today's circumstances, must be concentrated to be effective. Since workers must cooperate to concentrate capital, noncooperation is untenable, and we do not have voluntary cooperation.

The communist solution is to socialize the concentration of capital, in much the same sense that we socialize the concentration of directly coercive power in the hands of a more-or-less (and presently less rather than more) democratically elected government.

Must as I completely agree with anarchists that society of autonomous individuals more-or-less immune to organized coercion is desirable, we can't just declare an autonomous society. We must instead create a bridge to such a society. The specific set of social constructions we call "capitalism" cannot form such a bridge, not because it concentrates capital, but because it concentrates capital in the hands of private individuals, and almost forces those individuals to use that capital for their own individual benefit, without regard to mutual benefit.

Communism means, and has meant since Marx, to do the best we can with what we have today to build such a bridge: a bridge from a society dominated by economic and physical necessity to one dominated by each individual's self-actualization. To the extent that historical communist governments did not build such a bridge, they failed at the task I would have set for them, and at the task that Marx set for them. We can talk all we want about why they failed (did they jump or were they pushed?) but lack of success for any reason is failure.

But failure is not necessarily thorough discredit. The accomplishments of historical communist governments are notable and dramatic, and we can plausibly attribute their failures to circumstances external or accidental. The nascent Soviet Union first faced a bitter "civil" war openly backed and supported by the West, followed by the explicitly genocidal Nazi regime, followed by the implacable hostility of a nuclear-armed United States. And neither Russia nor China suffered through the century of armed conflict that established what few "Enlightenment" values that became part of the West's common social construction (and the West seemed willing and easily able to abandon those values in their relation to their colonies, leading to excesses as gross as the Belgian Free State, or the less malevolent but still socially distorting colonization of India).

It's not by any means a perfect or optimal solution, but communism still seems to be the best we can do presently to build an economic and social system that will indeed lead to the development of an autonomous society.


  1. I agree with you that right-wing anarchists/Libertarians don't seem to register the idea of economic coercion. They simply continue to chant their "equality of opportunity, not outcome" mantra. If rights are secured for us by force (which is the most sensible thing I've heard in a long time) then we can secure for ourselves whatever rights we want, which automatically makes Roosevelt's "freedom from fear" attainable. It also makes "the right of health care" perfectly plausible, as with any other right we might find attractive. Finally getting out of the yoke of "God given rights," as they have been proposed to us since grade school, is very liberating.

    It's a return to "might is right," but counter to monarch-provided might, using might established democratically.

  2. Wow, I missed this post when you wrote it, and only caught up with it when I went directly to your blog (instead of reading via Planet Atheism as I usually do).

    See, the first half of this post is why I don't bother to write political theory on my own behalf: someone else usually beats me to the punch, and does a better job. (The second half was good, too, but since it deals with your specific arguments it doesn't track what I was thinking.)

    The only thing I can add to this is that I have noticed a desire on the part of anarchists to take away the freedom to not cooperate in the way that they suggest. In an Anarchist world, we'll all be free -- as long as we only do the things the Anarchists approve, of course. Actually exercising our freedoms would destroy them.

    (And yes, I consider this to be symptomatic of the open source community too, typified by Richard Stallman -- what sort of authoritarian does it take to tell people they can no longer even mention the names of proprietary software programs?)

  3. typified by Richard Stallman -- what sort of authoritarian does it take to tell people they can no longer even mention the names of proprietary software programs?

    Link? I'd like to read that.

  4. Executive summary: Someone on the Gnome Foundation mailing list happened to publish a blog entry about Microsoft's Silverlining API, and Stallman came out with his wonderful gem of a statement that refusing to mention proprietary software in public was the minimum he would expect from members of the Gnome Foundation. Since Stallman was proposing thorough censorship as a minimum, one of the board members proposed that they should break Gnome away from Stallman's (increasingly restrictive*) GPL. A fracas (at least, a fracas over e-mail lists and blogs) ensued.

    An article about the whole thing, with links and more details, can be found at

    Read very much about Richard Stallman's public interactions, and you'll get the impression that the GPL would have a great deal more public acceptance if he had not been connected with it. The man doesn't really do much in the way of coding himself any more, and has never had to rely on the income from a program he has coded. He's very much a theoretical type when it comes to free software, laying down the law for others to follow without bothering to make sure his word is really feasible first.

    *Linus Torvalds, the man who started the whole Linux project and after whom it is named, refuses to update the Linux kernel to version 3 of the GPL. That should tell you everything you need to know about Stallman's brainchild.

  5. Interesting. Many thanks for the link and the summary!

    I'm getting ready to release a free (donation-supported) open source software system myself; do you have any advice?

  6. (Whew! This grew to a very long answer, far too long to fit in a single comment. So I'll be posting it in multiple pieces. Also: I apologize in advance if I'm telling you things you already know, or talking below your level.)

    My advice would be to think very carefully about how you go about it. I like the idea of open source software (and let me plug one of my favorite -- but currently very incomplete -- projects, Haiku OS, right up front) but there are multiple different routes you can take to get there. First there's the choice of license, then there's the choice of tools to make the code available, and then there's bug reporting.

    I feel something of an obligation to remind you that you don't have to make your code open source in order to make it free as in beer; for Windows and Mac OS (and Haiku!) you can just provide compiled binaries instead of source. That won't work very well on Linux or the BSD variants, though, because there are too many possible binary variants. The downside of this approach is that you have something of an ethical obligation to track down bugs and provide fixes, which you may not have the time or resources to do. (Figuring out what causes a crash on someone else's machine can be excruciating, even with all the tools available.) Of course, making your code open source does not guarantee that anyone will actually fix existing bugs, but it severely reduces your ethical obligations. The upside of binary distributions is that people are probably more likely to make donations to you than if they can grab the code and make their own version. That's not how it should work in an idea world, but it's how it usually does in the real world.

    There's a list of ready-to-use open-source licenses at But in practical terms, there are only three categories, and two of those categories only have one member.

    The GNU General Public License (usually referred to as the GNU Public License, or GPL, even though the GNU organization has some other licenses you can use) is the most radically open of the open source licenses, and v3 is the most radical of its versions. If you use the GPL, then your software is basically required to remain open forever, and anyone can fork at any time and you have no say. But in exchange, nobody can ever use your code in any context without also using the GPL, so if you like some new feature from a derivative, you can always see how it was done and incorporate it into your version. And that even applies to hardware manufacturers -- any hardware which includes your code, even in compiled form, must also provide access to their source code and any changes they may have made.

    The SFLC will sue if they notice someone violating the GPL, even doing so independently of the original authors. (Google "busybox lawsuits" for more details.) For this reason, proprietary software companies increasingly tend to be very wary of incorporating GPL code into their products, no matter how beneficial it might be to do so. Figuring out whether your proprietary code really violates the GPL requires advice from IP lawyers who understand code, and those aren't cheap; besides, the answer is likely to be "yes, so you'd better open your source and give the product away for free", which proprietary software companies don't like to hear. (You'll notice that the companies contributing to GPL projects like Linux, such as Cisco and IBM, tend to be hardware or server companies; they aren't really selling software to end users.)

  7. Part the Second:

    The GNU Lesser Public License (usually referred to as the LGPL) is less restrictive than the GPL, but it really only makes sense if you're working on a library (or other programmable interface, like a language interpreter) -- the main difference is that non-free/open code can use your project without penalty, provided they do not modify your project itself. (If they want to do that, then they have to make the source code for their version of it available.) If you use LGPL and do something new and interesting, you risk incurring the wrath of people like Richard Stallman, because they want the good stuff to be pure GPL to keep it completely out of the hands of proprietary coders. On the other hand, it's a good compromise if you want to make sure derivates are open while allowing businesses a free hand to use your code. (On the other hand, there is some community pressure on any LGPL project to go to the full GPL, which makes proprietary software companies nervous about even the LGPL.)

    Most of the other popular licenses (MIT, BSD, Apache, etc.) are variations on the theme of "you can use this code however you like, but you have to give me credit". (I admit that I didn't check the Eclipse license thoroughly, because it's filled with legalese and I have a head cold right now, which makes it hard to follow.) For this reason, companies which sell software (as opposed to selling hardware or server access) tend to want to use open-source code that is released under these other licenses. So if you actively want your code to be reused by commercial companies, you might want to consider using one of these. (Why would you care about that? Well, if you want lots of other people to use your code and make suggestions or feature requests, that's a good way to do it.)

    (Just a side note: the GPL forces all derivative coders to be open, which effectively requires that all derivative software be free -- as in beer, to use the tired phrase. It's kind of interesting to me that there are no licenses which require derivative works to be available for free -- as in beer -- but allow the source of the derivative works to remain closed, which is a technical possibility.)

    If you are the sole original owner of the intellectual property (or you have the agreement of the other owners), then you can usually change the license (or even release under multiple licenses for different purposes). Keep in mind, though, that you usually cannot revoke a previously released license. The only thing you can do is release a new version under a new license and hope that the bug fixes or new features in the new version are compelling enough to get people to use the new license. The old license will usually still apply to the old version, so it will be possible for people to fork the old version under the old license and ignore your new version entirely. Successful attempts to do this are few and far between, but it could happen. Of course, were you to move from a more restrictive license to a less restrictive one, then there would be no reason for that to happen.

  8. Part the Third:

    Once you have decided on a license (or multiple licenses), the other half of making a project open source is how you go about making the source available. One constant regardless of method is that the more time you spend maintaining the interface for the project, the less time there will be for you to actually play with the code. And the more important you are to controlling the project, the more the project will stagnate if you don't spend time on it. (So it may be a good idea to find some colleages to whom you will grant privileges. Be a bit careful, though -- people tend to identify themselves with their code/projects, so you don't want to grant permissions to someone who will later throw a snit fit because of version numbering. And if your own ego is easily bruised, maybe you shouldn't have colleages to begin with -- or perhaps you should explicitly give away control right at the beginning, and just become another code submitter.)

    For relatively small projects -- i.e. anything which isn't going to have thousands of programmers working on it at once -- something like will probably take care of the basic needs for hosting and control. (If you go with something like this, then for the sake of your users, fill in as much metainfo as you can. There are an awful lot of projects where the source code is the documentation, and that's a terrible thing for users.)

    If you feel like spending your time on building a custom web interface on a separate web server for those who want to contribute, then wiki/blog combos tend to be popular. But you'll need to figure out hosting and permissions and so on from scratch. This may be necessary if your project gets too active. Unless you are no longer interested in coding, you should probably try to stick with plain vanilla configurations of blog/wiki software -- programmers tend to want to reinvent the wheel, and although it can sometimes lead to innovative techniques, it's generally a bad thing for something as unimportant as the supporting structures for an open-source project.

    You can also just make a plain old non-automated website and make things available that way. If you want to be a single point of control for the project, that's convenient -- but it adds incentive for your contributors to fork, just for ease of contribution.

  9. Part the Fourth:

    Finally, there's bug reporting. Integrated systems like SourceForge tend to have this built in, but you can also use standalone systems like Bugzilla to handle bug reporting.

    There are two major considerations for handling bugs (as well as the actual fixing of bugs themselves).

    First, there's the user interaction component. Basically, you want to make it as easy as possible to submit a bug report, while at the same time as difficult as possible to submit one which does not contain the information needed to figure out what caused the bug. Remember to put the bug report URL (it's not a good idea to handle bug reports by e-mail) in multiple locations.

    If you can, find some way to make a log file (or, if you can manage it, a stack trace) easy to obtain. (One possibility would be to provide a GUI tool which asks the user for a location for a copy of your log file, and instruct them to run this and submit the output with their bug report. Creating such a GUI program would be roughly ten minutes of work on any modern OS using some kind of scripting language like AppleScript; the only trick is that log files aren't in the same location on every platform, so you'll need to figure out how to find them.) Don't assume that every user will know how to do this right, even if every user of your project is a coder and therefore is presumably a savvy user. Not every developer has bothered to learn the ins and outs of their system, and in any case if inexperienced developers are having a hard time getting your project to work, you should be willing to find out about it and do something to make it easier for them.

    Although you can try to work with less information, you will want: some contact info for the submitter (so you can ask for more details), what version of your project they were using, the OS and version they were using to run it on, a human-written description of what went wrong and what they were doing at the time, whether or not the bug appears consistently, and some sort of log file or stack trace. If your project is a plugin or some equivalent, then you'll also want the version (and any customizations) of the program with which it interacts. It's also nice to get some details about the hardware they were using, although in an ideal world that should be irrelevant for anything which is not a kernel or a driver. Make it clear during the submission process that bug reports which do not include the necessary information are unlikely to be fixed, and give instructions on how to do it right. If it is easy to search the database of bug reports, ask the users to search for their bug before submitting it, so you can cut down on duplicates.

    Once you have a bug tracking system set up, you need to manage the bug reports. Someone needs to find duplicate bug reports, look for bug reports on old versions which have already been fixed, weed out the occasional prank/misplaced feature request/crazy person, try to wheedle complete information out of overly brief users, and look for bugs which have been outstanding to try to prod developers to fix them. If you don't have someone actively doing this, then your bug tracking system won't help you as much as it could. (The good news is that this is a job which can be delegated to non-developers who want to help out with your project. It saves you time and makes them happy.)

  10. And, Finally:

    (And on behalf of open source users everywhere: you should periodically search for bug reports which have been closed because developers could not reproduce bugs reported as consistent on their own hardware, and reopen those reports if the submitter says the bug is still there. There are few things as frustrating as a program which always fails the same way, but which will never be fixed because the developers are unwilling to look for issues which don't effect them personally.)

    Some explicit questions to consider:

    1. Do you want to keep working on the code yourself, even after it fills the purpose for which you originally intended it?

    2. Do you care if other people sell your code (either directly or as part of some larger product) for profit?

    3. What do people have to do to make it okay to use your code in a context other than the one you explicitly envision? (Statement of credits? Publication of full source code?)

    4. How active do you imagine development on your project will be?

    5. How much time do you want to spend on maintaining the project, as opposed to the code?

    6. Do you mind letting other people make major decisions about your code, such as version numbering and accepting submitted changes?

    7. How much documentation is needed for your project? Who is going to write it, how will it be distributed, and how critical is it for the documentation to be up to date?

    8. Would you be upset if someone forked your code? What if the forked version became more popular/important/active/mainstream than your original version?

  11. Thanks a lot for the info!

    Do you mind if I publish the whole thing as a blog post (of course with attribution)? This is great stuff.

  12. Eh, you don't even need to give attribution -- this is stuff that a lot of people have been saying. Anyone could have collected this information with a little time on Google and some open-minded reading of people's complaints about existing open source projects.

    Then again, saying anything even remotely negative about the GPL tends to cause GPL fans to attempt to rain destruction on you, so having some plausible deniability might not hurt. (And they can cause hassle if they try -- "slashdot effect" is named after a pro-Linux site for a reason.)

    All I really ask is that, if you use my writing, you do some more proofreading for the final version. Egad, did I really say there were three considerations and then refer to the second one as "the other half"? And did I say "idea" for "ideal"? Why yes, yes, I did. I go now to self-flagellate. Or maybe just to bed, so I can shake this dratted cold.

  13. Since I have been licensed to be sententious on the subject, I put together a list of lessons to learn from common complaints about open source software. Again, this list is written assuming that you have never heard any of it before, so apologies in advance if it comes across as somewhat condescending. And again, this list is too long for a single comment, so here's part 1:

    - Decide up front why you are doing this project, and keep it in mind. Is it to provide yourself with a currently non-existant product? To provide other people with useful code? An ego trip? Having a clear idea of what you expect from the project will help you make decisions about the direction of the project, feature requests, and design issues. If you are writing code for others, remember to listen to them when they ask for things. If not, don't be surprised when a fork of your project eclipses the original.

    - Learn to take criticism of your code (and your GUI design!) without offense.

    - Decide up front whether the target audience of your project is going to be programmers or end users. Programmers will want greater configurability, but tend to be more forgiving of features which don't work yet. (They may view them as a heads-up on the future direction of the project.) End users hate it when you give them access to a feature which does not yet function, but are more forgiving of inflexible design.

    - Linux users are often more like programmers on other platforms than end users on other platforms -- they may assign greater value to flexibility. If you are coming from Windows or Mac but targetting Linux, you may need to change your priorities, and vice versa. (For example, Linux users like skinnable GUIs, but are used to features which don't work yet. Mac users want their programs to work, but generally don't care about whether a GUI is skinnable.)

    - If you are supporting Linux and you don't have other developers using other distributions, do your users a favor: go to DistroWatch's distro popularity chart and read the top X most popular distributions of Linux show for some small value (such as 3 or 5) of X. Make a VM of a plain vanilla installation of each of these distributions. Before releasing a new version of your project, make sure that (a) it works properly installed over the old version on each of your VMs, and (b) it works properly as a fresh installation in a pristine copy of the VM. Update your VMs to the latest versions of the distributions every six months or so. This is a fair amount of work, but your users will be happy you did it.

    - Try as hard as you can to avoid reinventing the wheel. If a target OS has something built in, use the version which is built in. (This is extra true for GUI widgets, but also applies to things such as deciding where to write scratch files or manipulating standard data types.)

    - Try not to add new features if existing features do not work.

    - Do not embed jokes (or other prose) in the project code, configurations, or any included sample data files. Doing so is asking for trouble via Murphy's Law.

    - When adding new features, do not expose an interface to change settings which only currently work with one value. Just assume a default for now and add the controls when the other settings work.

    - Most people like choice to be present, but dislike being forced to consciously make a choice. Unless a setting genuinely requires a custom value, or cannot be changed later, just assume a reasonable default instead of pestering the user.

  14. Part 2:

    - Any file your program writes which it may need to reopen later should have an easily-parseable mark at the beginning (or as meta-info, or in the file name) which gives the version of the project. If you do not do this, Murphy's Law guarantees you will later change the file format and wish you had.

    - It is nice to allow users to install multiple versions of your project on the same computer. (Obviously, some projects can only run one copy per computer.) If possible, plan your code so that different versions can run concurrently. If you can't make this happen, but the project is such that a user might reasonably expect it, make sure you say so conspicuously.

    - Make sure that newer versions of your project can import not just data from as many old versions as possible but also configuration files. It is not too rare for a user to need to upgrade a very old version of a project to the latest version. Users who discover that you made this easy will love you.

    - Programmers like to be able to run the same code using different libraries which have the same function, and often write code which can depend on different libraries at will. (This is known as a "decoupled interface".) End users may be happy that this is an option, but if given the choice generally would prefer that things Just Work with some single library. Don't write decoupled code unless you have a good reason; it makes bugs much, much harder to track down. (You know how Linux has these recurring problems with sound? Decoupled ABIs -- ALSA, PulseAudio, OSS, etc.) And if you have already got a working version of your project which has a particular dependency, it is usually a waste of developer time to decouple that dependency. (The one exception is when a library is being deprecated or discontinued.)

    - If a feature is really hard or really boring to code, it's probably something your end users will really find useful. Unless your project is really just for your own amusement, give priority to hard- or boring-to-program things which are uncommon. (I warn you that this will make it sheer unbearable torture when someone forks the project and gets the credit for your work.)

    - There is a difference between builds and actual releases. Do not encourage normal end users to use non-release builds. You will cause your bug reports to skyrocket without gaining much (if any) useful information. (If you are doing an open beta, that's different.)

    - If you are building a GUI project, then you are too close to the code to decide if the GUI is intuitive. If you find yourself frequently defending your GUI design with "well, it all makes sense to me" or "you just don't understand the program well enough" then you have done something wrong. Stop being defensive and listen to your users.

    - If your project is for end users rather than programmers, do not make them edit a configuration file unless absolutely necessary. (And if you must, do not build in a programming language unless this has been actively requested multiple times by different users.) Instead, write a GUI to do the configuration, or at least a web interface like CUPS has. And keep it up to date. This will make your program easier for new users to install and operate and make it harder for users to produce unusable configurations. It will also guarantee that all supported configuration options are obvious to the user, rather than hidden; this will cut down on the "how do I make it do X" questions.

  15. And Part 3:

    - When writing your configuration interface (or, failing that, documentation), make sure to explain what the different values control. Sometimes it's acceptable to just label them (as, for example, "frames per second" in a video program), but there is a strong tendency to abuse this option. If possible, show your configuration interface to someone who has never used your program and ask them whether they can figure out what each options does.

    - If you are writing a GUI program, then your user should never be required to use the command line. If they are, you have failed. No exceptions.

    - Refactoring code or changing programming languages or toolsets is more often than not a waste of time. Think very hard before doing it -- do your users want to wait months for the next version for improvements they can't see?

    - Try hard not to let your program overwrite anything during installation or first run. (Sometimes it is unavoidable.) When you find you must do this, ask for confirmation first if at all possible.

    - Never assume that it's okay to modify the contents of a section of the filesystem just because you have write permission. Ask the user for a location first, or add a configuration option. (The exceptions are, of course, sections of the filesystem set aside specifically for program support.)

    - "It works for me" is not sufficient cause to ignore a bug report, unless this project is just an ego trip.

    - "You aren't paying me, so I refuse" is not the right way to deal with a feature request, unless this project is strictly to satisfy your own needs.

    - "Send me a patch!" is not a good way to handle either a bug report or a feature request, although it may sometimes be necessary. (Yes, you have limited time. But if you expect non-programmers to use your code, don't expect others to patch your code.)

    - "Because I can" is never a good reason for GUI design. If your GUI does something which cannot be justified in terms of ease of use, then at best it is a waste of development time.

    - When designing a GUI, remember that different users prefer to work using different methods. Some people like menus, some people like toolbars, some people like contextual menus, and some people like keyboard shortcuts. Multiple forms of access to features are extra work, but they will help your project appeal to more people.

    - Make sure to test your GUI (if any) using a minimal system -- that means a mouse with no scrollwheel and the fewest number of buttons possible in the OS (1 for Macs, 2 elsewhere), and a keyboard without function keys or a numeric keypad. (You can just pretend; no need to buy new hardware.) If there is a feature which cannot be accessed under these conditions, your GUI has a design flaw.

    - Unless you are a hardware or compiler expert, most "optimizations" you perform aren't.

    - Reducing launch time is only important if your project will be launched a lot or the launch time is significantly longer than other projects of the same category. Fixing bugs or speeding up non-launch operations is probably a better use for the time.

    - There's a whole host of common coding/design/management mistakes known as "anti-patterns". If you have never done so before, go to the Wikipedia entry on Anti-Patterns and read through them. (I have covered a few already, without going into detail.)

  16. Excellent tips, Vicar. I've been programming for 30 years, and your thoughts mirror my own to no small extent.

  17. Well, once again these are hardly original ideas -- I can't claim to have deduced any of them from scratch.

  18. I was going to stop posting comments to this thread, but I saw a news item which was both timely and apposite to my comments on how Open Source movement gives you freedom only as long as you obey them.

    First, some background. It is a longstanding complaint of hardware manufacturers (and certain other programmers) that the Linux kernel ABI is uncomfortably volatile -- if you want a device to work, you will at least potentially need to update the drivers with every new version of the kernel, sometimes even making radical changes as major features are removed.

    This volatility is not a necessary outcome of open development, but a conscious decision on the part of the kernel devs. A fixed ABI would limit their freedom to radically change the internal workings of the kernel -- they might have to save major changes for major version increments like proprietary software companies do. So they shift the work of support to the device makers instead.

    Now, you've heard of Google's Android OS (or you must be the only techie in the English-speaking world who hasn't). Android is based on the Linux kernel. To make Android work comparably on lots of different hardware, Google had to freeze the kernel ABI. (They also brought back some old process-scheduling code and added some new features: a new type of resource locking, a new driver model, a new framebuffer system, and a security system.)

    Google complied with the GPL. The source for Android is available. They also released patches back to the main Linux kernel team, with notes. They are, in short, playing by the rules and then some.

    Nevertheless, a representative of the kernel devs, one GregKH, is now complaining because Google has created a mutually-incompatible kernel, and the main kernel team apparently wants the new features (or at least compatability) but can't be bothered to integrate and maintain the new features themselves. This despite the fact that Google had to fork the kernel to add the features they wanted, which is an understood part of how open source licensing is supposed to work, and also that Google has already done extra work on top of what was required. It isn't enough because there are also unwritten -- and hypocritical -- rules about authority; you don't cross the kernel devs.

    The main concern is that device makers will prefer the stable ABI and write drivers for Android but not ordinary Linux. Linux would do well to fear this -- Google's approach has been to write good code and then make it open, while the Linux approach has explicitly been to write open code and hope somebody will then make it good. It's fairly obvious which one will appeal more to a normal person.

    (I'd be willing to bet a small amount of money that Android will overtake mainline Linux on the desktop within 5 years. And also that some other tech company, encouraged by Google's example, will fork-and-freeze the Linux kernel as well.)


Please pick a handle or moniker for your comment. It's much easier to address someone by a name or pseudonym than simply "hey you". I have the option of requiring a "hard" identity, but I don't want to turn that on... yet.

With few exceptions, I will not respond or reply to anonymous comments, and I may delete them. I keep a copy of all comments; if you want the text of your comment to repost with something vaguely resembling an identity, email me.

No spam, pr0n, commercial advertising, insanity, lies, repetition or off-topic comments. Creationists, Global Warming deniers, anti-vaxers, Randians, and Libertarians are automatically presumed to be idiots; Christians and Muslims might get the benefit of the doubt, if I'm in a good mood.

See the Debate Flowchart for some basic rules.

Sourced factual corrections are always published and acknowledged.

I will respond or not respond to comments as the mood takes me. See my latest comment policy for details. I am not a pseudonomous-American: my real name is Larry.

Comments may be moderated from time to time. When I do moderate comments, anonymous comments are far more likely to be rejected.

I've already answered some typical comments.

I have jqMath enabled for the blog. If you have a dollar sign (\$) in your comment, put a \\ in front of it: \\\$, unless you want to include a formula in your comment.