Friday, May 22, 2009

Open Incentives

When I was writing code for a living, I loved working with open source products. I loved being able to download a tool and get it running without having to lobby for a purchase order. I loved the fact that when I encountered an error using one of those tools, I could step through the code and see where the problem started. I was fascinated by the proliferation of open source projects and by the communities of developers that emerged around these projects. What made some projects succeed and others dwindle? Who was finding the time and incentive to build them? When I started spending more time with business (as opposed to technical) questions, open source posed new intriguing questions. What does open source mean for my employer, SirsiDynix? Many have suggested that open source ILS systems are a disruptive innovation that will transform the library automation industry. Will it? If so, how? My business cards say “Director of Product Strategy”, should I be pushing SirsiDynix towards an open source business model?

Some thoughts in progress: The open source projects that really take wing seem to have one of two things in common—thousands of dependent developers, or big audiences that will support an advertising funding model. PostgreSQL and Eclipse, for example, are successful open source products that many thousands of developers rely on every day to do their basic work. Of those thousands, a relative few actually get invested in solving problems and contributing time and code. Software engineers have various incentives to pitch in. It may build their resumes, they may feel good by contributing, or they may just need the product to do something it doesn’t, so they get in and fix it themselves. It takes the many thousands, though, to percolate out a critical few that will move the product forward. Mozilla Firefox is a successful open source product that survives on advertizing revenue. 85% of that revenue comes from Google. Stay tuned, though, now that Google has its own web browser.

Library automation is a niche community. We have a smattering of solid developers in our midst, but the thousands who rely on the ILS to do their daily work are nerds of a different feather. I don’t see us percolating out a critical mass of invested contributors. The advertising model seems culturally at odds with the library world. True, there are lots of patron eyes out there, but hitting them with adverts in the OPAC feels a bit like shouting at the study table, or mud wrestling in the archives room.

I have not seen products really fly when funding comes from support and implementation fees. This model assumes that the product is hard to install and configure. The incentive structure leans to support and documentation, but not really new development. Innovation and strategic planning has to come from developers outside the business model. Outside developers, though, are incented to solve their own particular problems, not build the product of the future. There is a difference.

For now, then, the incentives for innovation seem rightly aligned in a business model based on proprietary code. Support is a cost in this model so SirsiDynix does better when the product is easier to deploy, configure, and maintain. We’re working hard on that right now. SirsiDynix is openly profit driven and will only succeed if it solves problems that competitive offerings don’t. SirsiDynix is not a side project. Our survival depends on being ahead of the change curve in the industry. That’s my take. For now. But I’m open to other arguments.

Jared Oates
Director of Product Strategy, Engineering


  1. "I have not seen products really fly when funding comes from support and implementation fees."

    This is such an odd statement coming from a library vendor. What is SD's "funding model" if not from support and implementation fees?

  2. Ok, I'm confused. The open source library companies I know of like Equinox and Liblime do not use advertising revenue as their primary source of income from what I can tell.

    Indeed, advertising revenues aren't really that common in a lot of open source projects. Most systems that rely on advertising revenue are not open source but instead are things like web services which are often by nature closed source. (Facebook for example).

    So those companies models seem a lot like yours. So what makes your model different than others, besides you don't share the code? Equinox and LibLime both need a steady supply of happy customers, right?

    The advertising argument seems orthaogonal to the issue of whether or not SD should be using more open source or releasing open source. I could twist it in a similar way, ask another question, let's say a proprietary business (not necessarily you) got offered a significant amount of money by a private company to add a feature, such as directly link to that company's website with a "purchase this book". They estimate they'll get enough money to make up for any loss in customers really upset by this addition. What can an individual customer do to block this? Proxy solutions, javascript hacking, or similar methods end up being needed, if they don't violate a license.

  3. Oh, someone reminded me of another example of a closed source proprietary model that is a webpage/webservice. Blogger, right? Owned by Google, supported by ad revenue, and offered for "free" but the source is not released. I could be wrong about the latter though.