As I’ve talked about in this space in the past, I’ve been coming to some conclusions about free software (open source, or whatever you want to call it): the economics of it, like anything else, are rooted in scarcity, and if you don’t have a bit of that scarcity yourself, you have a lot less leverage

This line of thought comes from the age-old question “how to create free software and make money at it?”. This is a very important question for me, because I enjoy hacking on free software very much, and would love nothing more than to spend my days doing so. Creating new things, though, rather than working as a “system integrator” and tying pieces together with the smallest amount of glue possible. It’s obvious that there is plenty of money to be had for people who simply use free software for their own ends. But what are those ends? We live in a world of scarcity – not everyone can have a fancy car, the nicest house in town, or the fastest computer. Market economies work via the exchange of scarce goods and services. If you have nothing to trade, you have nothing. Now, free software is worth something. Worth a great deal – that is beyond the shadow of a doubt. But since anyone can make a copy, there is no scarcity – once it’s out there, you can’t trade for it.

So… where does this leave our potential free software creator? Let’s think about some of the ways around this problem.

• You could, as some have argued, decide that since software has aspects of a public good, and decide that it should be provisioned by the government. Computer users pay taxes and there is a ministry of software that pays people to work on infrastructure type projects like the Linux kernel, Apache web server, and the like. Whether you like this idea or not probably depends on what you think of governments, free markets and so on, and thus becomes a much broader debate, but suffice it to say that it’s not going to happen soon, because free markets do provide software, so most governments aren’t likely to fiddle with the system in radical ways.

• Work on contract to create custom systems for clients. This works, up to a point. Since the initial system doesn’t exist, there is your source of scarcity. The client wants it, and won’t get it – free or proprietary – unless they pay you. It’s also worthwhile to think about the “chain” of trade in this case.

  Where does your client get their money? If you’re writing free code that will simply become a cog in their proprietary system, the actual money comes from the scarcity they have created, so while you may be writing free software, in one sense, you’re simply offloading the burden of creating scarcity to someone else, who is then able to pay you for your time. The other possibility is that your client works in the “real world” of scarcity directly – they sell books or beer or cars or something else where the product is, by its nature inherently scarse.

  In this case, they still have the leverage – you work to help their business, but they are the ones in the driver’s seat. Your work isn’t worth much without their scarcity-based business. And they’re not very sensible if they pay you for things that aren’t directly related to their business. So it’s going to be harder to create something new and interesting from scratch.

I’ve alluded to it in the past, but consulting operations have several problems, especially when considered from the point of view of someone who wishes to create software:

• The more time you spend putting existing pieces together, the better you are doing financially, because you can finish the project quicker, in less time, and so have more of a margin. These sorts of business will tend towards system integration, rather than the creation of new things. That’s not a bad thing, and I mean no disrespect to those who are in that business, but it’s not really what I want to do, and it certainly doesn’t answer the question of how to write new free software and get paid to do it.

• When you create a one off solution that is not completely tailored to one client, if you make something that’s proprietary, and know you can sell it to a few more people, perhaps you can beat the free software guy on price, because you can afford to sell yours at a lower price, knowing you’ll spread the costs of producing it over a few clients. If the free software guy manages to sell the same free thing to several clients, you have to ask how ‘free’ the software is in the sense that it is apparently controlled tightly enough that these other clients can’t come into possession of it on their own. Once, again, scarcity.

• It’s not a business that ‘grows’ as well as having a proprietary product, because it’s very linear. To make more money, you have to add more people (of uncertain quality, I might add). With the proprietary product, on the other hand, you could likely sell 100, 1000 or 1000000 copies with a workforce of the same order of magnitude. This leaves you a bit more breathing room – if you’re a consultant, the minute you take a break, be it a vacation, or even go to sleep, you’re not making money because you’re not engaged. That’s sort of a scary prospect as one ages, and needs to dedicate time to other things in life. At 20, I could spend all day every in front of the computer. At 30+, now I have a wife. Maybe there will be kids some day. A successful product-based business would allow me time for those things that a billable-hours business might put more constraints on (of course, there are obviously no guarantees that any business will be successful, but for the sake of argument, we’ll treat failure as failure and not worry about it more).

So, there you have it. In one way or the other, to make money at something in the long run, you are going to have to find and sell a product that people cannot effortlessly get for free.

Well, not really, but some people might think so, or feel intruded on…

To back up a bit, and put that in context, I’m currently contemplating ways of making Stuff To Do, my web based todo list/time tracker/work organizer more able to track when a user is active. Currently, it marks you as active if you do anything at all in its web page. The reason I adopted this approach is that I want the program to help the user out, not make the user a slave to the program (ok, switching tasks, hit start..stop…stop stop start stop start start…bleagh!). However, even this approach relies on the user keeping the window open, and visiting it every now and then, which is less likely if you get ‘in the zone’ and are concentrating on your own work. A couple of methods for dealing with this come to mind:

• Platform specific binary that can be installed to keep track of when the user is active. This would be the most accurate way of determining that information, but also the most intrusive, and probably the least convenient for end users, who would have to install something on their machines.

• A reminder. Instead of tracking the user, try and get their attention to come back to the web page and let the app know they’re still alive. Not very appealing, because the concept of “bug the user so they pay attention to me”, which is not in keeping with the “be unobtrusive” philosophy of the system.

• A small pop-out window with “active?” javascript code embedded in it. On Linux (Gnome’s window manager at least), you could even set this little window up to follow you around the desktop in order to register the fact that you’re active. Advantages: web based, more accurate than the current system. Cons: annoying window following you is….well, annoying. Having a little window open all the time might be an annoyance as well.

Thoughts? Would you use any of these, or consider any or all of them too high a price to pay to keep track of your hours?

A while ago, PragDave wrote about using Rails migrations outside of Rails.

I wanted to be able to have things work ‘just like in rails’, so I hacked up a quick script that runs all the migrations in the files/ directory:

require 'rubygems'
require_gem 'activerecord'

if ARGV[0] =~ /VERSION=d+/
version = ARGV[0].split('=')[1].to_i
else
version = nil
end

@logger = Logger.new $stderr
ActiveRecord::Base.logger = @logger
ActiveRecord::Base.colorize_logging = false

ActiveRecord::Base.establish_connection(:adapter  => "mysql",
:username => "dbuser",
:host     => "localhost",
:password => "xxx",
:database => "yyy")

ActiveRecord::Migrator.migrate("files/", version)

It would be even nicer to have a config file, but that should be very easy to do with YML.

I run it like so: ruby domigrations.rb. I believe that the Migrator.migrate call isn’t documented, so I don’t know how safe it is to count on it, but for the moment things seem to work quite nicely…

I created a mobile phone shopping app a while ago with Hecl, and since it seems to have become fairly popular, I did a second, more polished version that is still very simple to use: ShopList.

I think it’s a good way of utilizing a mobile phone and the web together – you enter the list of things to get in a web page, then the phone fetches that list. Realistically, inputting a long grocery list on a phone would drive you mad, whereas with this application, it’s quite fast, and what’s more, it makes use cases like this possible and simple: I’m going to the store, so my wife creates a list on the web site, and sends me the list id, which I use to fetch the list when I’m at the store.

I received a very interesting email the other day from an individual who works for the state of Oregon seeking to forge ties with high tech companies abroad. They don’t have a great deal of resources, but they do have some contacts, and are open to dealing with even relatively small organizations.

I have to say that there is some really interesting stuff happening in Oregon in terms of open source lately (beyond Linus Torvalds living there), so if any European companies, or university professors are interested in going over to have a look, I’d be more than happy to pass the information along.

Steve Yegge posts an article about this that, the other thing, and statically typed functional programming languages. In it, he compares Haskell to something you can:

"build beautiful, lithe marionettes with"

Unfortunately, I haven’t had the time or inclination to learn Haskell (yet), but I have used Erlang professionally, so I do have a bit of experience using a functional programming language. What comes to my mind isn’t marionettes, but clockwork. That’s a purposefully neutral word, in case you were wondering. An enthusiast might say “a finely crafted swiss watch”, and a detractor might grumble “a windup toy”. In my mind’s eye, the concept is that in functional languages you get this succession of things happening one after the other that happen precisely the same way, if the program is wound up just the same each time. To paraphrase:

Do this with the result of this with what this produces when given  
this input that is derived from this function which takes the  
result of this other thing after calculating the result of 
something that is derived from the output of a function that ...

And so on and so forth…tick, tock, tick, tock.

While I can appreciate that in some ways, this is likely to produce clean programming, in other ways I am less convinced of its practicality. If you’ll bear with a poor comparison, sometimes programming is like a song. You do the tricky section, then you go back to an easier section and catch your breath for a bit. That seems to work out in a language like Ruby or Java fairly well, depending on how densely you like your code. You get sections with DoThisAndThisAndThatWithTheResultsOfSelectThisFromTableXYZ that you have to slow down to think through. And then:

• You assign the result to a variable.

• Which gives you a few lines to

  • slow down
  • consider where the program is

• And then

GoToTheNextTrickyBit where ManyThingsHappen.

All in all, you wind up with a sort of ebb and flow that works out pretty well if you’re in tune with the code being written, going from intense calculations, to a line or two where you do no more than store things in a variable, take a breather, and prepare for the next important stanza.

In my limited experience, I have to say that I didn’t always get that sensation from Erlang (which in some ways is apparently less “hair shirt” oriented than Haskell). You always had to be writing something with an eye to where it was coming from, and where it was going.

Without a doubt, this produces code that is more compact in terms of meaning and functionality, but at times it leaves a guy like me, who grew up with Basic, C, Python, and so on with the desire to say “woah there, nelly”, let’s take a breather and sort things out a bit in a few variables before moving on to the next bit of fancy code gymnastics.

What I’m curious about is what will catch on from academically oriented programming languages like Haskell. The people working on them are without doubt very smart, and there are some interesting concepts being bandied about (pattern matching is pretty cool, just to cite one). But academia doesn’t always produce things that catch on with the average Joe programmer, either, and while the more elitist out there may attribute this to simplistic reasoning such as ‘well then Joe is just stupid’, I think that the more thoughtful language crafters will attempt to ascertain what works, and what doesn’t, and perhaps we will see the Ruby of functional languages emerge from Haskell, the Smalltalk of functional languages.

What do you think?

I generally try and keep this journal focused on technology issues, but this is one bit of frivolity I couldn’t pass up:

Andrew Savory and Steve Loughran mention the idea of an Apache Bike Team.

I’m in! I’m always happy to take people for a ride through the nearby Colli Euganei and/or Colli Berici if they happen to come through my section of northern Italy, which really is a wonderful place to ride a bike. Spring, Summer and Fall are best, but even in winter it’s often nice (about 10C and sunny today, although I’ve been stuck inside with the flu this week…argh).

(I’ll also take a minute and plug my friend’s bike racing/training/touring camp business too: raceitalia.com/)

Now if only I had more time to be out riding myself…

I’ve been using Rails for about a year, and I am, in general, quite satisfied. It really is a big step forward in terms of web programming, and I’ve found the whole experience very enjoyable. In a year I’ve managed to crank out a number of sites in my spare time (in between various other activities such as the occasional bike ride and Hecl hacking):

• linuxsi.com – a site in Italian helping people to locate Linux-friendly computer retailers.

• builder.hecl.org – lets you create Hecl mobile phone applications from your web browser.

• libreriaminerva.it – a small bookstore in the center of Padova, specializing in rare and antique books and prints.

• stufftodo.dedasys.com – my own vision of an ajaxy todo list that plays nicely in a business environment, where it’s important to be able to share tasks.

As promised, one of my goals is to shift a bit towards producing open source software as a side effect of revenue generating work. The first small result of that is the on_idle plugin I packaged up for Rails. It’s the code that Stuff To Do uses to tell whether people are active or not. Installing it should be as simple as:

./script/plugin install http://svn.dedasys.com/public/on_idle

It’s just a few lines of Javascript code that are wrapped up in a way that makes it trivial to use from Rails views:

def on_idle(timeout, options, wakeoptions)

<%= on_idle(600, {:url => { :action => 'notify_idle' }},
                 {:url => { :action => 'notify_wake' }}) %>

• timeout: the number of seconds before the user is considered ‘timed
  out’.

• options: the action to perform when the user goes idle.

• wakeoptions: what to do when the user ‘wakes up’.

Let me know if there is anything I should fix/change/improve. If this plugin works out, I will post, in short order, a plugin that improves the default Rails drag and drop functionality.

Regarding my previous posting, the first thing that I wanted to release is called “Stuff To Do“, and is a simple, elegant priority queue for getting things done. It lets you reprioritize, track time spent on tasks, generate reports on time spent, and most importantly, share with other users. You can create groups of people who can view one another’s tasks, and give tasks to other users, all via a very intuitive interface (javascript is, however, required). It’s all meant to stay out of your way as much as possible, even the time tracking requires only that you visit the browser window every so often to let it know you’re there, rather than fiddling with (and sooner or later forgetting about) start and stop buttons. Perhaps it’s not accurate down to the second, but the idea is to give you a general idea of what you’ve been up to, rather than something you have to slavishly click on all the time.

The group interface is also meant to be easy to use to get a quick idea of what other people are working on, or share tasks with other people. For instance, if you’re a project manager, you could create a bunch of tasks, and then just drag and drop them to other people in the system. You can’t change other people’s priorities (yet), because I think it’s better if you simply ask them yourself – technology isn’t a substitute for communication!

While I work on the paypal interface (I looked into Google Checkout, but it’s still got some limitations), I’m going to let people sign up for the group-enabled version with six months for free. It won’t cost too much per user when I roll it out in any case, probably somewhere south of $20. The basic version is likely to remain free as long as I can cover hosting costs.

I’ve been using it myself at work and home for the past month or so, along with a few of my colleagues, and it seems to fill a nice niche in between more heavyweight issue tracking tools like JIRA, and the index cards/bulletin board we’d been using.

Check it out – I hope you like it! In any case, let me know what you think.