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 didnt 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. Its nice to have options. Oct. 7: There has been an update to the SpringSource maintenance policy.
