Tips on paying for free software

by Mik Kersten, October 6th, 2008

Comments on The Server Side have been voicing concerns about SpringSource’s new maintenance policy, which gives incentive to purchase a support contract if you’re building mission critical apps on Spring. I’ve been amazed at some of the dialog, which ranges from suggestions that SpringSource has neglected its community to recommendations that they should instead ask users for donations. Since well before they became a partner of Tasktop, I have had a deep respect for the innovation and productivity benefits that Rod Johnson and SpringSource have been delivering to enterprise Java. I know first-hand how much work it takes to foster and support an active community around a new technology. When a technology makes it big, it must transition to also supporting the demands of commercial adopters, otherwise its adoption will stall. While the tone of the dialog on The Server Side has been improving, some of it confuses the notions of free software, open source community and commercial solutions.

Clearly everyone loves free software. Free software rules. That is, as long as somebody pays. If nobody paid, free software would be very boring. Innovation requires one form of investment or another, and without ongoing investment, innovation cannot flourish. The neat thing with software is that we have various options for paying.

We can pay with our time, which is typical when first adopting open source tools and frameworks. This is a great option for technologists, because it supports experimentation and encourages involvement in technical communities. For example, at Tasktop we needed a reporting solution for the time tracking feature we released in July. We experimented with Eclipse BIRT, invested considerable time in adapting that code, got involved with the community channels, and have now committed to maintaining that integration in our tool. In a similar fashion, we have been interacting with the Bugzilla community and codebase since we make very heavy internal use of Bugzilla. In both cases, the time investment has paid off.

There’s also the more traditional approach of paying with money. Tasktop Pro supports accessing all of our Microsoft Outlook and Exchange data in a task-focused way. Instead of investing our time in doing more COM programming than we already have to, we instead purchased software from Moyosoft to do this for us. It was under $2000, and reduced our development and maintenance risks. A key feature of money is that it makes it much easier to measure the total cost of adopting a solution.

In the past couple of years, the trend of paying with our eyeballs has become more popular. It’s not quite as painful as it sounds, but you have to watch out for the “death by a thousand cuts” that can result from distractions of advertising. At Tasktop, we have been using the free and ad-supported Google Apps, since the Tasktop product integrates with Google Calendar and Gmail. Our entire mission is about less being more and ensuring that the user interface shows only the relevant information, and the presence of ads is at odds with this mission. So we’re now making the switch from the ad-supported, pay with your eyeballs Google Apps, to the paying with money $50/user/year version.

Finally, if you can manage it, paying with other people’s time and money is definitely cost-effective. There are open source projects whose code comes from the countless volunteer hours of people who love to make the world a better place with great software. There are alternate economical models at our disposal too. My favourite is the gift economy of Burning Man, which I have been frequenting for years, where all get to enjoy a temporary but fully-functioning city whose citizens forego trading money or bartering for sharing gifts and smiles instead.

In my opinion, gift economies are not feasible for driving major software innovations. As soon as an innovation gets traction, it needs to cross the chasm from techy early adopters to the very different requirements that come from an onslaught of commercial adoption. The adopters of the technology who think they will get a free ride, and invest neither time nor money, take on substantial risk. They have neither a contract nor the community influence necessary to adapt to the ongoing evolution of the technology. For example, I’d be concerned if SpringSource didn’t provide 24×7 support to the major airlines who use their Web Flow technology, because I’m already having a hard enough time getting my Christmas bookings without the Air Canada site going down. Similarly, if Tasktop didn’t provide additional support, training and integration for Mylyn, the task-focused interface could not stay on its amazingly fast adoption path, because too many of the new teams adopting it want a commercially supported product instead of investing their time in the open source project.

When adopting a free technology or solution, it’s a good idea to explicitly plan on how you’re going to pay for it. One of the great benefits of open source is that you can start by paying with time, and when your dependence on the technology increases, you can identify committers or vendors who can support you beyond the time investment that you’re willing to make. Or you can decide to get involved with the project. If it’s governed on the principle of meritocracy, as is the case with all Eclipse projects, you will have some assurance that it will be time well spent. It’s nice to have options.

Oct. 7: There has been an update to the SpringSource maintenance policy.

11 Responses to “Tips on paying for free software”

  1. raveman Says:

    What you think about ?

  2. Oleg Zhurakousky Says:

    Nice points Mik

    As to, IMHO it is quite irrelevant for several reasons.
    First, building spring is very simple (less then 5 min). And as a guy who wants to play with bleeding edge technologies I have been and will still be making my own builds from the trunk as I do with other projects.
    Second, when the morning comes and I have to go and act out my role of an architect on some large scale Spring based commercial project. . . at that time I am already locked on a specific stable version of Spring (i.e., 2.5.5). The state of the latest and greatest build is no longer my worries. In fact what I do worry about is not even decided by my, but rather CIO, who’s gonna want some support for this stack and the fact that Spring up until now didn’t have a formal maintenance policy was making such CIO scared.
    So, back to, the argument of making builds as the convenience is prety lame. . . first I see no convenience, second – don’t waste money on hosting it. . . use torrents or something, cheaper with the same results

  3. Mik Kersten Says:

    Regarding, I think that Oleg’s comment makes the key points. In addition, having spent time with Rod and other SpringSource engineers like Christian Dupuis and Juergen Hoeller, I know just how deeply these guys care about serving the needs of the open source community. The challenge with is that it assumes that SpringSource won’t do a good enough job serving the communities’ needs, whereas I believe that they will.

  4. Mik Kersten Says:

    Here’s a criticism that came up on a dzone post that I want to address.

    Wow if you do not pay for 24×7 support your site goes down at Christmas, yes 3 months from now, because apparently Spring is what keeps it up and running or at least decided whether it should crash or not. Not the OS. Not the application. Not the management tools. Not operations. Without Spring and support your site is dead in the water at Christmas.

    My point of view on this, which may or not be the point of view of SpringSource, is that if your web app builds on a framework, that framework, along with the OS, the database, and your application, is responsible for the stability of your app. Since the Spring Framework issue is heated right now, we could also argue this in terms of another framework like .NET. If you just updated or patched your ORM mapping or other database tools, and introduced an incompatibility between that and the framework that fails to manifest itself until pushing production, you could have a problem. If the framework is providing a WS layer for you, you may need security and other patches for that WS layer as exploits become known. In other words, my point of view on this is that so much functionality traditionally associated with OSes and app servers is being captured by the frameworks, especially those that provide IoC, that it helps to think of them as another sort of runtime.

  5. Tasktop Blog » Blog Archive » Interview: How Software is Built Says:

    […] Tasktop Blog Mik Kersten and friends on focus and flow « Tips on paying for free software […]

  6. Virgil Says:

    Great article Mik, I work with Eclipse BIRT as well and often have to articulate the reasons someone should consider the Actuate “pay-for” versions for their project… It seems there is always a balancing act between your time, money, and project requirements to determine how much you should build and how much you should buy. The bottom line I get from this article is that you are always paying for software…even when it’s free.

  7. Simon Says:

    Hi! We are two guys from Sweden and we´re writing an essay about the global warming. We wonder if it´s okey if we use your picture of the scale with the clock and the money? It would be awesome!

  8. Wesley Coelho Says:

    Hi Simon, the picture of the scale with the clock and money is a royalty-free stock image that can be purchased from:

  9. Simon Says:

    Thank you sir! Now the essay will be awesome!

  10. Wesley Coelho Says:

    No problem, glad we could help!

  11. Tasktop Blog » Blog Archive » Eclipse Foundation Board Elections Says:

    […] Tasktop Blog: Tips on paying for free software […]

Leave a Reply