Ben Hughes

30 Jan 2012

Lessons from my first open source project

Todotxt.net is my first real open source project. I’ve written and shared some dodgy PHP scripts in the past and thrown some code up on google code, but this is the first time I’ve engaged with the OSS community. And I’ve learnt a couple of things.

Open standards are better than open source

The thing that drew me to using Todo.txt in the first place was that at its heart is a plain text file that you can hack in whatever editior, on whichever platform, you choose. It turns out that that also makes it a very attractive thing to develop for.

No matter how open Gina’s source was, if I had to dick around with some proprietary storage format I wouldn’t have even looked at creating a Windows client for it. In fact, I didn’t look at any of the existing source code when writing todotxt.net – I just wrote to the standard.

Open source is awesome

I was pretty blown away when people started downloading my little app and even taking the time to report bugs. After all, it was at v0.1 and appropriately hacky and buggy. But then something awesome happened.

I woke up one morning and saw that someone had submitted a bug report. As I started to reply I noticed that I had a github pull request fixing the same bug. While I was sleeping, someone reported a bug in my app and someone else fixed it.

Inexpressibly awesome.

Have an upgrade mechanism in place. Always

At version 0.8 things were humming along nicely – a couple of dozen people had downloaded the app and a couple of people were contributing code. Then Gina blogged about it and Lifehacker picked it up. Suddenly I was getting 600 downloads a day.

The only problem was, v0.8 had the new intellisense functionality which turned out to be pretty buggy. I got a fix out quickly, but had no way to tell the 600 people who had already downloaded the buggy version. I’m sure more than a few people were put off by the random crashing and probably never looked back to see if there was an update.

A couple of point releases later I added in an upgrade notification. It’s terribly basic, but it works. In future projects I’m going to have update notifications in some from in before I release even an early alpha.

Git’s not scary, and github is awesome

I’d hackily played with Git a couple of times, thinking my Mercurial knowlege would let me wing it. It didn’t. Because I wanted to use github (it’s what all the cool kids are doing) I figured I should put some time into finding my way around the basics. To my releif and surprise, it’s not as forboding as it intially seems.

And github, well, you can see why it’s become the defacto OSS repository. The cool kids are using it becuase it’s frakking fantastic. It’s just so easy to share code, track changes, accept patches, manage issues. It’s really pretty special.

5 Jan 2011

Come work with me!

It's coming up on a year since I left the public service and joined the team at FinalBuilder. We're recruiting again so I thought I might run through what it's like here and why I enjoy it so much.

The Products

To be honest, when I started I wasn't sure what to expect. It was a nice surprise to find that the products (FinalBuilder, FinalBuilder Server and Automise) are of a very high quality and are really appreciated by our customers. The new product we're working on is following in the same vein.

It's great to work on great software.

The Work

I'm programming probably 90% of the day. The other 10% is spent doing support or brainstorming. The new product (which gets most of my attention) is being built in the latest MS stack technologies: ASP.NET MVC, WCF, (Fluent) NHibernate, jQuery etc. Having a mostly old-school background (Oracle stored procs, .NET2.0 WinForms etc) I've learnt a lot. It's been awesome.

When I say "programming" I mean coding, designing, testing, releasing etc. End to end stuff, from whileboard to deployment. You're not sitting in the corner being handed a spec with no input.

The Environment

I'm writing this on my quad core, 8GB RAM, dual 24" monitor dev machine. The keyboard I inherited when I started was bugging me, so the boss bought us all new ones. I've got admin access to everything: my machine, our local servers and even our web host server. If I need a VM, I just run one up.

It's quiet. At first I thought it would bug me, but it turns out that once again Joel was right. Being able to work without interruption is wonderful. Oh, and there's a coffee machine, water cooler, buscuits and fruit etc.

Basically: we're appreciated and well cared for.

The Culture

We're only small, so there's no hierarchy. Which means there's no ladder climbing or political bullshit: you turn up, do interesting work with smart people, then go home. You're trusted to do your job and not screw things up.

The CEO is a developer and spends most of his time writing code. There's no translation from management speak to dev speak. There's no wondering about what the vision for the company is and what we're trying to achieve. There's no talk of "maximising our value proposition", either. And in almost a year we're yet to have formal meeting.

Support, although it doesn't take up too much time, is an important part of the culture. There's a strong focus on genuinely helping customers. It's pretty common for us to get a bug report or feature request, make the changes and send the customer a new build within a day. That level of responsiveness blew me away initially.

But the risk!

If you're a public servant it might seem like a huge risk to leave safe a job to work for a small dev shop. That's how I thought for a long time. Although we're small, the company has been running profitably for 10 years. You're not coming to work in some guy's garage (although, of course, that's how the company started).

Personally, I think the cost of spending your career doing something you don't really like is much worse than the risk involved with going after what you want. And perhaps I shouldn't mention this, but I work less hours with less stress on more interesting stuff and get paid more than I did as an APS EL1.

And if it turns out you were wrong, there's a lot of APS jobs in Canberra...

Who we're looking for

You have to be in Canberra and be able to competently write and speak English. We can't really negotiate on those two.

Ideally you'd have many years real-world programming experience and be comfortable with C#, web services, Javascript (esp jQuery) and HTML. But if you're an experienced dev with a different tech background (like I was) or even someone relatively inexperienced but passionate about programming, drop us a line.

Qualifications matter less than the passion to create great software and the desire to learn.

If you'd like to talk to me before you 'officially' contact the company, I'm @benrhughes or ben@benrhughes.com

23 Nov 2010

How do you make money off software?

This is my response to a question over at programmers.stackexchange.com on making money from software when the marginal cost is zero.

Background : supply, demand and equilibrium

Most people know that supply and demand work together to determine price: this is almost intuitively obvious. But the 'how' is a bit more complex than that. Over the long term in an efficient market, price will end up being approximately equal to marginal cost (that is, the cost of making the last unit). This is called equilibrium. This happens because whenever the price is higher that the marginal cost, competitors will move into the market and price their product between the marginal cost and the orginal price. This continues to happen until P = mc.

So how do you make a profit?

Market equilibrium doesn't happen immediately. If you release a product with no direct competitors, it takes time for others to create competing products. During that phase you charge whatever you want (this is essentially a temporary monopoly). How hard it is for competitors to turn up is known as the 'barrier to entry'. In a highly efficent market, barriers to entry are low and competitors arrive quickly, pushing down price. So you have basically two strategies for making a profit:

You continually come up with awesome new products and ride them until the market catches up, then move on to the next thing
You do whatever you can to increase the barriers to entry

The second point can be done a few ways: some legal, some not. For example, you can buy up all your competitors, but at some stage you'll attract the attention of the regulators. Or, you can make products so well or so complicated that they're hard to compete with. Or you can look at ways of locking in customers so switching is difficult. In the long run though, price will tend towards marginal cost. You're delaying the inevitable, but you might make a lot of money in the process.

The third way

The third way to make money "off software" is to use it as a loss-leader, and make your money off a complimentary product: eg service and support.

Final thoughts

It's important to note that this is true for all products, basically. Even those with non-zero marginal costs. Whenever P = mc, there's no profit. The reason that the service industry is so attractive is because it's relatively easy to differentiate your service and hence charge a premium for it.