Russ Nelson

In a free market, over time, competition in the production of a commodity product will eliminate all profits. Bread-makers can sell their bread for enough money to cover the cost of the capital invested in the bakery, the cost of the flour, yeast, sugar, and water, the fuel needed for firing, and the salary of the baker. They can earn no more money than that. If they did, then another bakery would be established which would price its products lower, splitting that profit between the customer and the owner of the new bakery.

In order to earn a profit, you need to do something special (called a franchise). This could have several forms: you could create something new that nobody else has. You could have an exclusive territory assigned to you (as in the traditional franchise, such as McDonald's etc). You could have help from the government, in the form of a patent or copyright. Or you could have a professional certification, such as a law or medical degree, without which one is prohibited from practice -- and possession of which is controlled by other lawyers and doctors who are sure not to give out too many.

In the case of software development, you can copyright and/or patent your software (although it's dodgy that both apply, since the theory is that they can't both be used on the same work). Or, you can write your software in such a way that it is inextricably tied to a piece of hardware which only you sell. Or you can develop an expertise with a piece of software which nobody else can or will reproduce.

Or you can simply not worry about getting a franchise because you know that only certain types of people have the ability to program. If true (and I believe it to be true) then programmers will forever command higher than usual salaries. And the more demand for programmers, the better-off will be programmers. And the more use of software, the more demand for programmers. And the less expensive is software, the more wide will be the use of it.

Every process is a mix of inputs. The ratio of inputs depends on the cost of these inputs. The process gets changed over time to handle the varying cost of the inputs. If one of them becomes cheaper, it becomes a larger factor in the production.

I believe that there is sufficient evidence to say that Open Source and free software lowers the cost of production of software, and hence will ineluctibly raise the salary of programmers, even as these programmers give away more and more of their software.

All of this, of course, is in complete opposition to Stallman's GNU Manifesto. He attempts to rebut objections to GNU's goals. He repeatedly makes the claim that free software will reduce programmer's pay. I claim otherwise. Hopefully Stallman has changed his mind.

I recently got myself a Flickr Pro account, and have been using Flickr for more of my photos. I find myself more and more annoyed at the rough edges in the Flickr user interface. For example, when you want to delete a tag from something, you click on the [x] to the right of the tag. Flickr asks you "Do you want to delete the tag?" Cancel/Ok:

This is almost certainly the wrong thing to do. It annoys people because the website is (in effect) saying "Hey, that might be a stupid thing to do, so I'm going to slow you down so you can think about it." The first couple of times people might pause to think (but what they're likely thinking is "you stupid computer, I told you what to do".) After that, when they want to delete a tag, the action will be "Click X; Click Ok", with no pause for thought.

That is how people think. That is how people are able to learn a complicated game like chess, or go. People chunk information and actions together. This allows the forebrain to go on thinking about other things while the rest of the brain carries out an action previously decided-upon. If an action requires a confirmation, the hindbrain will confirm it as part of executing the action chunk.

The way to work with human congnition rather than against it is to allow for Undo. Undo isn't a new idea -- we were using it 25 years ago. Undo works well with the human brain because it allows actions to happen without confirmations, but it also allows the forebrain (which operates slower than the hindbrain) to realize that it has made a mistake, and correct it with an Undo.

Flickr isn't all bad. They do use Undo sometimes:

When they add an image to a set, they add an indication that it's in the set over on the right, so the "OK" part is useless. They should skip the dialog entirely and insert a temporary "UNDO" below the set listing. Even when they do use UNDO, they spoil its operation with a confirmation:

Of course I want to remove it from the set! That's why I just clicked on UNDO, right?

Following the confirmation is another useless "Click OK to indicate that you are still alive" box.

Of course it's been removed, because the set listing is now gone. The proper way to handle this is to grey out the set listing on the right, and add an "UNDO" button below it.

Even if you've implemented your website using Open Source software like Linux, Apache, MySQL, and PHP, you don't escape the low quality typical of proprietary software unless your software is Open Source.

It's easy to volunteer other people to fix problems. In the Open Source world, the typical response is "great idea; send a patch." Flickr lives in the Web 2.0 world, not the Open Source world. Their software sucks just like any proprietary program. We can't fix it. Only Flickr can fix it, and hopefully, they'll at least fix the problems I've outlined here.

Many, many programs written in C or C++ use a file called "config.h" which contains #define statement that control the compilation of the program. These programs are also nearly always build using 'make'.

I claim that these two attributes are in conflict with each other. Or, in layman's terms, "config.h sucks". The problem is that when you have multiple options in config.h, every file which may be compiled differently depending on the values defined therein, must be recompiled whenever config.h changes.

The correct way to do compile-time options is to have a config subdirectory containing a multitude of .h files, each with its own #define in it. These are easily managed because each file has only one #define, and when the source file mentions the thing being defined, it needs a #include of that config file. The 'make' program is trivially informed of these dependencies by looking at the files included in each source.

So, when you change one option, only those files which depend on it will get recompiled.

I wrote this blog posting while waiting for a program to recompile because I changed config.h .... and it's still not finished recompiling on pretty studly machine. Ahhhh, it just finished.

Of course, this is completely disrupted when you rewrite your Makefile (as GNU automake does), but that's a subject for a different posting.

Are you a patent holder, wondering how to write software which implements your patent? Here's my advice: Patents expire. Towards the end of the patent's lifetime, you want to be trying to transfer the patent's franchise over to the relationship between the patent-holder and the licensee. That can be done with closed-source software, but you risk competitors writing their own software. With Open Source software, as long as you manage the relationship with the user correctly, you end up with a franchise.

Long before a patent expires, you have ZERO NEED for closed-source software. ZERO. NONE. The purpose of a patent is to give you ownership over the idea. The purpose of closed-source software is to give you ownership over the code. But if you already have a patent, you own the idea. No need to own the code -- in fact, owning the code only hurts you, because it closes you out to people who would improve the code, or even to people who would create new patented works based on your patent.

If you have a patent, you NEED open source software.

Are you having trouble licensing the Adobe Flash player? Apparently, Adobe makes it difficult for some people to license their Flash player. I don't know why -- you'd think they'd be all about the money. But regardless, the Gnash project is happy to license its Flash player to you if Adobe won't license their Flash player. Go Get Gnash now.

I'm speaking at, and attending, the Irish Web Technology Conference 2008. I'll be giving a talk on "Choosing an Open Source License". It's being held in Dublin City February 26 / 27 / 28 / 29. I hope to see you there if it's an appropriate conference for you.

I finally got to put my hands on the ASUS Eee PC, at The Computer Guys, here in Potsdam. It's a solid-state subnotebook. Runs Linux. Comes with Open Office, a few games, a web browser. Has Ethernet, Wi-Fi, three USB, one SD slot, and audio in and out. Supports SDHC. Seems very sturdy.

It's wicked small, being a subnotebook. Tiny keys, but you can almost touch-type on it. The key feel is good enough, given the size. The nicest thing about it is its size. It's smaller than a hardcover book. If I wasn't already flush with mobile devices (Toshiba laptop, XO, n810, n800, n770, and various iPAQs), I would definitely buy one.

I believe that autoconf is broken. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use.

The trouble with autoconf is in the configure script it creates. There are several problems with configure. First is that it does standard tests about the operating system, but it doesn't save the result of those tests anywhere. In other words, if you are compiling package A and package B, and they both use autoconf, then both of their completely re-do their configuration tests. If you re-run configure, it remembers the expensive results it got the last time you ran it. But results are not shared across packages.

configure is also used to pass in configuration parameters for the package. These parameters can point to system libraries, or define optional features, or allow for cross-compilation.

configure is also used to detect the presence or absence of necessary system libraries. I've seen it cache that information, and not notice that the library has been installed between runs. I haven't seen that happen lately. Maybe that bug has been fixed?

In all of these cases, the problem is that even the least change invalidates every bit of compilation. Configuration changes aren't tracked between configure and make. When you run configure, it creates a completely new Makefile, so the wise person always runs make clean after running configure.

That's dumb. It's just plain dumb.

The purpose of make is to track dependencies between files. You give it a makefile, and when something is older than something it depends upon, it gets re-built. OR, if something depends on something that will be re-built, it also gets re-built. And so on.

Put configuration changes in individual files, each with its own timestamp. In the makefile, record each configuration's dependency tree. When a configuration entry is changed, that change ripples through everything which uses that configuration, but only those things which use that configuration.

If you object to this, then let me ask you: if you had this, then when would you ever use make clean? make clean is in essence a reboot of the make system. It's an acknowledgement of a bug. So why does every autoconf package support make clean? Simple: because autoconf is buggy.

The Microsoft FUD is laughable, while the patents are a serious problem. But the fact that they're trying to gain currency from it -- without actually naming any of the patents -- is a joke. We need to treat it as such.

Think about it this way: what if they said "We have 235 nuclear bombs?" If they actually thought that they were all functional bombs, they would say "... and we'd be happy to demonstrate one." They haven't done that, so it's reasonable to conclude that they're of wildly varying quality.

The problem with Microsoft's threat is that they really don't know which of the 235 bombs work, and which don't. Do they show us their best bomb? If they do, and we defuse it, they've given it up for nothing and haven't proven anything except that they're foolish. Do they show us their bomb least likely to work? What would that accomplish? We'd just laugh at it when it fizzled.

Microsoft is the one with the problem here, not us.

If asked to think of the defenders of democracy, you might think of Marines and a Navy corpsman raising the flag on Mount Suribachi. It's a very stirring image, but no, you'd be wrong. Think, instead, of the little old ladies who are present when you vote. They are the true bastions of liberty, the heros who save our elections from corruption.

How do they do this? Well, understand first that they aren't buddy-buddies. They're poll watchers; present to ensure that the vote is accurately recorded. They're Democrats and they're Republicans. Their loyalties are not to each other, or to their knitting. They're making sure that neither of the major parties corrupts the vote.

They do this by understanding how the votes are recorded in the voting machines, and by how the voting machines count the votes, and how the counts are removed from the machines and recorded and reported. They have sufficient experience with the machines and the process to be able to recognize when things don't work right.

This isn't true with electronic voting machines. The ways that they can be corrupted are too foreign to them. They don't have years of experience with the $FOOBAR model of electronic voting machine. And I'm not sure that open source software running on the machines is all that much of a help. Maybe after the women graduating from MIT and Harvard and CMU become little old ladies, open source will be a source of trust for them.

The solution is in the poll watcher system, not in the software. Software is too blind and uncertain, too soft. We need a machine which works a certain way, and which always works that same way. We need software without bugs, so it doesn't need to be changed. Ever. Once we have that, then the poll watcher system can learn to trust the operation of the machines.