A Free Software Business Model
I have lately been trying to convince the lead developer of Publishers’ Assistant that he ought to be switching technologies for his next version of the software — and he ought to adopt a new business model along with it. The reason for this is that the software is currently written in Visual FoxPro, a proprietary programming language and data environment. Microsoft is pulling the rug out from under FoxPro: they’re not releasing any new versions, support for the latest version ends in 2015, and they’re not going to release the source for any version because it contains “too much intellectual property” (translation: “We’d rather continue to sell expensive SQL Server licenses, thanks”). Granted, it will still continue to work, at least until Microsoft stops releasing 32-bit versions of Windows, but it will continue to age and there’s nothing we can do about it.
For this reason alone, it’s worth looking into other technologies, but there’s another, more business-oriented reason: FoxPro doesn’t run on Macintosh machines, which are widely used by small publishers. As long as we stick with FoxPro, he estimates that about half the market will be inaccessible. At the moment, Publishers’ Assistant is a 1.5-man company (I’m counting myself as .5), so there’s a lot of room to grow — if we can reach the people who would most benefit from the software.
I am suggesting Python as a replacement for FoxPro. There are a lot of good reasons to do so, in my mind:
- it’s free software, so we know the underlying technology will never go away
- it makes development really fast
- it’s cross-platform, so our 1.5-man operation doesn’t have to maintain three different codebases to support Windows, Macintosh, and GNU/Linux users
- the Django framework will make developing web-based and GUI front ends for the same back end a snap
- and so on
To go along with a Python version, I’m suggesting a new business model based on a free software license like the GNU GPL, which I will outline below. I would really appreciate comments on this, in the spirit of collaboration. Which parts do you think are the weakest, and which the strongest? How can we fix the weaknesses?
Here’s what I’m thinking so far:
- Release a bare-bones Python version as quickly as possible. Distribute the source code free of charge, to encourage as many early-adopters as possible, and release it under a copyleft license to encourage anyone who contributes to share upstream. The bare-bones version won’t have any frills like an installer or auto-configuration for a database; these will be developed later as users ask for them. It will have a plugin-based architecture, so that new features can be developed and installed individually.
- Get users involved in specifying new features. This will happen on a wiki: users post new feature requests, discuss their requirements for them with each other and with the developers, and directly modify the feature specification. When the document becomes stable, it will be “frozen” and opened for bidding.
- Let users bid on new features. This is the cornerstone of the plan: users decide how much they’ll pay to have a particular feature developed, and put in a “bid.” Each frozen feature specification has two associated dollar amounts: the minimum needed to begin development, and the (estimated) cost of development. Once the bids reach the minimum, we start writing the code; once we’re done and the bids have covered the cost, we release the new feature. This allows users to distribute the cost of custom development between themselves, so it’s never out of anyone’s price range, which in turn means more work for us.
- Charge more for support. We currently spend about 90% of our time supporting users and working on custom features, but these only account for about 50% of our revenue. In my view, this means we’re undervaluing support (and overvaluing copies of the software), which is risky and, frankly, not terribly successful. Support is an important part of why people use Publishers’ Assistant, so if we’re going to keep spending most of our time on it, we should get paid accordingly.
That’s the basic idea. To me, this plan looks great because, in addition to making the software available to a whole new set of users, it gets users involved in the community, it automatically prioritizes development on the features users need most, and it makes sure we get paid for our valuable services, which isn’t always happening now. But why would publishers buy into it? Before you start yelling that the GPL isn’t business-friendly or that no one has any incentive to pay for individual features if they can wait for others to pay for them and get them free later, let me offer a few more thoughts.
“Why will anybody start using this software?” Well, we already have a fairly large Windows user base, and regularly get requests for a Mac version. At the attractive initial price of $0 with the promise of ongoing development that is responsive to publishers’ needs, along with good support, new users shouldn’t be too difficult to find. Current users are likely to make the conversion when development and support for the FoxPro version ends, as long as we make it easy for them.
“Why will anybody pay for feature development?” The software sells because there is a need for industry-specific accounting software that’s affordable. Users already pay for feature development to a certain extent (we write custom reports and new features all the time), but most of them probably can’t afford to pay us on their own for all the new features they could use. By letting them share the costs, we’re likely to get more feature requests. The value of new features is that they allow you to do something when you need to do it. The more quickly a user needs a feature, the more they’ll be willing to contribute to its development, since development only proceeds when a feature has enough financial backing.
“Won’t your users run if they see support costs go up?” Maybe, maybe not. I’m betting not, because good support is what they need most: many of them need help with basic computer concepts like directory hierarchies. If the higher cost of support is offset by the lower cost of the software itself, I doubt many users will object — especially if they look at how much other companies charge for support subscriptions.
Of course, there are some hurdles here. Like any new business, getting this one running smoothly is going to be something of a bootstrapping process. There are some psychological hurdles to get over (some people may be less willing to use software if they can get it free of charge, for example), but I believe that this basic approach will be better for both our users and for our business. So, how about it, dear readers? What have I missed? Are you convinced?