A Comparison Of Various Software Revenue Models

One of our first tasks at yumpty.com is figuring out what revenue model to use.

To do that, I put together a comparison of various options.

What did I miss?

Name	Strategy	Pros	Cons	Notes
Old School	Charge a lot for a license, and a lot for upgrades and support.	Lots of revenue (if not profit) from each sale. Captive user base if you can get away with proprietary data formats. Recurring revenue stream if you can keep convincing users to upgrade.	Horribly expensive up-front development costs. Enterprise/government sales. Four-legged sales calls. Weird revenue-recognition issues limit ability to please users with new features outside of planned (and charged-for) upgrades. Users can wake up one day and realize they're paying way too much for your software and start looking for alternatives. License schemes are inevitably hacked.	Works well for professional software that performs highly specialized tasks and that needs skilled support (CAD/CAM, circuit design, etc.). Licenses can be node-locked or floating.
Pay Once	Charge a lot for a license, but provide perpetual upgrades and support for free.	Customer loyalty after getting them to cough up the one-time payment.	No additional revenue from customers, despite their loyalty. Better hope you can continue to make more new sales.
Worry About It Later	Give the software away in order to get network effects, then figure out how to make money.	Everyone says this is the way to start software companies these days. Easy to get VC buy-in. Speeds time to market because v1 of product doesn't have to be very good because it's free.	Running out of money while waiting for network effects. Giving up bulk of control of company to VCs, because they're the only people with enough money to pay for the overhead (including ever-increasing support costs) while waiting for network effects. Few areas remain in which there is not already a clear winner of network-effects race.
Free With Ads	Give the software away in order to get network effects, and charge for ads.	Same Pros as "Worry About It Later". Worked great for Google.	All of the Cons of "Worry About It Later" (because ads won't pay until network effects kick in), plus: Ads annoy users, and can look cheesy, reducing appeal of your site. If site provides a service to a company, ads for company's competitors annoy company.
"Freemium"	Give the software away except for premium features, and charge for those.	Same Pros as "Deferred Monitization". Free gets the network effects, while charging generates revenue. Worked for Evernote.	Have to be extremely careful deciding where to draw the line between free and premium features; get that wrong, and either free won't be usable, or it will be so useful nobody needs premium (in which case site degenerates into entirely free).	Fees are typically a monthly subscription, but other approaches could be used. Fun fact: Evernote was 15 minutes from bankruptcy before being saved by an investor.
Tiered	Charge for different levels of features and/or service, but always charge something.	Always generates revenue (if not profits). Entry-level tier can be very inexpensive, but still cost enough to avoid the Cons of the various free approaches.	Users may only opt for lowest tier, reducing profitability.	Fees are typically a monthly subscription, but other approaches could be used.
Flat Rate	Charge a single fixed rate for unlimited access to all features.	Simple for users to understand. Always generates revenue (if not profits).	Users that only want a small subset of the features feel they are subsidizing the power users.	Fees are typically a monthly subscription, but other approaches could be used.
Crippled	Give away a version of the software that is missing key features and/or has limits on size, execution speed, number of calculations, support, etc. Hope users see enough potential in the software they pay to remove limits.		If limits are lax enough for users to get some decent experience with the software, they may not need anything more than that. If limits are strict, users cannot test out the software to see if it will actually scale. License schemes are inevitably hacked.	Freemium-on-the-desktop?
Time's Up	Provide a fully featured version of the software that stops working when the trial period expires. Hope users see enough value in the software they pay for it.	Users aren't hampered by limits, and are able to really test the software.	Users may only need to use the software for a brief period, which they can do without paying anything. License schemes are inevitably hacked. Time-based schemes can be defeated by running in a VM with a skewed clock.
Nag, Nag, Nag	Provide a fully featured version of the software that pops up an annoying modal dialog on launch. Hope users see enough value in the software, and are sufficiently annoyed by the modal dialog, to pay to make the dialog go away.	Users aren't hampered by limits, and are able to really test the software.	Users resent being deliberately annoyed. Scheme for suppressing modal dialog can be hacked.	A variant of deliberate annoyance: give away a fully featured version of the software that has ads, and offer an option to pay to turn off the ads.
Guilt Trip	Give the software away, but ask for donations.	Works great for wikipedia.	Appeals to users' better nature, which may or may not be effective. No guarantee of running without losses.	Can be simple donate button, or concentrated donation drive (like wikipedia).
Per Drink	Charge a tiny amount for each operation performed by user.	Nicely fits scalable cloud-computing hosting model, because revenue growth and hosting charges are both fine-grained. Tininess of charged amount can entice users into signing up.	Users underutilize product to avoid charges, which diminishes acceptance. Users don't like not knowing how much they'll wind up owing. Some users feel like they're being nickel-and-dimed.	Probably a better fit for service APIs than for end-user UIs.
Platform	Build a platform and share revenue with companies that write applications for the platform.	Worked for Salesforce.	Nobody will write apps for a platform that isn't popular, and a platform won't be popular until it has apps. Which means many of the same Cons as "Worry About It Later"
Consulting	Give the software away, but charge for consulting.	Consulting rates can be pretty good, particularly if the software becomes popular. Being free, the software stands a chance of becoming popular.	Scale of company is limited by rate at which qualified consultants can be added.	A good model for an independent software developer.
Support Only	Provide support for a product sold by some other company.	No software to write or maintain.	Company selling the product may fight you, because they intended to make money on support. Same scalability problems as "Consulting".

The Tyranny Of Extroverts

Here's a book that provides insight into why some people love open cubicles and a highly collaborative/noisy environment, and others don't:

http://www.amazon.com/exec/obidos/ASIN/0307352145/

It's unfortunate that the extroverts got the upper hand, because it's easy to work as an extrovert in an environment designed for introverts, but the converse is not true.

The author lists some contributions made by introverts. For example, the theory of relativity. Who knows what other contributions we're forfeiting, or at least slowing down, by creating environments in which introverts cannot be productive?

Open Cubicles Must Die

"The cynic knows the price of everything and the value of nothing." - Oscar Wilde

In 1987, Tom DeMarco and Timothy Lister published the first edition of "Peopleware: Productive Projects and Teams".

The book discusses many reasons software projects fail, and provides numerous recommendations for making projects succeed.

Part II of the book discusses the effect a bad office environment has on productivity, and recommends (among other suggestions) private offices as a significant productivity enhancer. The book provides quantitative evidence to substantiate the recommendation. And the book eviscerates the productivity claims of cubicleware vendors, which are shown to have no substantiation (the book calls those claims "proof by repeated assertion").

Fittingly, the book is out of print.

If anything, in the decades since the book was published, things have gotten worse (other than getting rid of P.A. systems). We are in the grip of an industry-wide pathology that produces expensive, flow-disrupting buildings.

How did we get here?

A lot of it has a lot to do with the counting of beans.

It is easy for a bean counter to count tangible things, like square feet.

It is not easy for a bean counter to count intangible things, like lost productivity due to a noisy work environment yanking programmers out of flow.

Suppose at some point a bean counter notices that their company spends more for facilities than "comparable" companies spend. This seems to the bean counter like fiduciary irresponsibility, so the bean counter launches an investigation.

Because the bean counter cannot count intangibles, the bean counter does a poor job of counting beans, and works up an Excel spreadsheet that shows how, if they get rid of walls and doors, and reduce the space each programmer gets, and eliminate bookshelves, and generally pack programmers into "pods" where they're practically sitting in each other's laps, the company will save a bundle.

On paper at least.

Intrigued by the putative savings to be had, the exec staff--sitting in their capacious, private, quiet offices--decides to engage the services of a cubicleware vendor to "work up" some designs for how the building could look. (Note that open cubicles are by this point a foregone conclusion, and that by involving a cubicleware vendor as the consultant, we have an instance of bid rigging so egregious that if this was a government contract somebody would go to jail.)

The designs are very slick. Spiffy in color, appealing in the abstract, the revamped building will "facilitate collaboration" (and who would question the need for that?), foster "inter-departmental serendipity" (which also sounds desirable, whatever that is), and so forth.

Nobody asks the programmers for their input. Or they do ask, but when the programmers say they want private offices so they can focus on work, this is dismissed as "impractical", even though drywall is cheaper than cubicleware.

The building is revamped, the programmers move into it, and are pissed off because they feel like they're regarded as interchangeable, revenue-producing, chunks of meat. Morale drops and productivity goes into a tailspin.

Adding insult to injury, the company newsletter makes a big deal about how the building, in a triumph of form over function, won an AIA award for "design excellence".

Those programmers who stick around find ways to circumvent the limitations of the building. For example, they take refuge in the server room (lots of white noise), or work at home.

But these strategies ultimately backfire, because the bean counter's minions notice that a lot of cubicles--the ones occupied by programmers hiding in the server room or working at home--are empty, and conclude that the building was in fact overprovisioned--that there could have been smaller cubicles, and fewer of them. Inevitably, the bean counter concludes that cubicles shouldn't even be allocated to individual programmers, but instead should come from a pool, first-come/first-served.

Because programmers are now sharing keyboards and mice, they share flu germs, and occupancy rates go down again. As does productivity.

To make up for the loss of productivity, the company needs to hire more programmers. But where to put them? Clearly cubicles take up too much room. Programmers should just work on long tables, like medieval craftsmen.

Meanwhile, the aggressive reduction in facilities costs is noticed by other companies' bean counters, who don't want to look like spendthrifts based on the latest "comparables".

And so continues the industry-wide death spiral.

Another reason we have open cubicles is due to differences between how programmers work and how the execs making the decisions work.

Execs are people people. They like to meet new people. They like to shake hands. They like conversation. They're extroverts.

Cubicleware vendors are also people people. They're in sales, so of course they're extroverts.

Programmers are, well, if you're a programmer you know what we are. It's not that we're necessarily ugly, or antisocial, but we're a lot more likely to send an IM to somebody 10 feet away than to get up and walk over there to talk. We like to get into flow and stay there. We like to solve problems.

When people people design a work environment, they design it how they like to work. Which involves a lot of face-to-face interaction with other people, long phone conversations, open airy spaces, etc. It's almost the exact opposite of the conditions that foster flow.

A few companies ago, Lisa was in a cube farm at a Fortune 50 company, concentrating, when some ninny of a people person walked into the area and, apparently discomfited by the unfamiliar sound of work getting done, said: "There isn't enough visitin' going on".

Visitin'.

Honestly?

Another reason we have open cubicles is that private offices are seen as a "perk". But they're not a perk, they're a software-development tool, and an effective one. Programmers don't care about status or prestige. They care about being effective. And they need good tools to do that.

Unfortunately, many execs do care about status and prestige, and they see private offices as a perk. It's a problem of semiotics.

Another reason we have open cubicles--and this is a self-inflicted wound--is that some of the newer methodologies emphasize collaboration, pair programming, etc.

But one person's collaboration is another person's pointless interruption.

When people are yakking around a programmer who's trying to get into flow or stay in flow, that constitutes involuntary collaboration. It's like being on an airplane before they banned smoking--there was no way to escape.

With private offices, programmers can always opt into collaboration by opening their door, sitting down in a communal work area, etc.

Without private offices, programmers can't opt out of collaboration. Which is a shame, because at some point, somebody, somehow, has to actually write some code.

But, you say, the programmer can always put on headphones. Yes, they can, except that page 78 of the second edition of Peopleware explains why that's a bad idea (a Cornell study showing that creativity is hampered by listening to music while programming).

The saddest part of all of this is that if companies would focus on maximizing programmer productivity instead of on minimizing facilities costs, they could accomplish a lot more work with far fewer programmers, which would save so much money in salaries it would dwarf the incremental cost of private offices.

Penny-wise, pound foolish.

Not all companies make this mistake. For example, when Adobe was building its headquarters in San Jose, they asked the programmers what they wanted, and then did something crazy: they listened. (Guess what the programmers wanted.)

Sometimes I get the argument that young programmers prefer open cubicles and more collaboration, but how would young programmers know? Did a lot of them previously work in large, quiet, private offices? Doubtful--cubiclitis has been infecting the industry since the 1960s, which is longer than young programmers have been working (indeed, longer than many of them have been alive).

Claiming that young programmers prefer it this way implies they ever had a choice. But they didn't have a choice, so there's no control group, and this is just more self-serving nonsense.

I'll close with a visit a few companies ago to one of the largest cubicleware vendors in Silicon Valley. We went there because we were opening up a development center, and needed furniture. The vendor took us on a tour of their facility, which doubled as a showroom and their headquarters. As the tour lady stood there telling us about the merits of this or that piece of furniture, I noticed some employees of the vendor in the background, in the accounting department.

They were glaring at us, because we were making too much noise.

Some interesting articles about or related to this topic:

• http://www.bizjournals.com/buffalo/stories/2001/07/16/focus2.html
• http://www.bosti.com/public.htm
• http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html
• http://www.joelonsoftware.com/articles/fog0000000050.html
• http://www.joelonsoftware.com/articles/BionicOffice.html
• http://en.wikipedia.org/wiki/Open_plan#Which_is_best.2C_open-plan_or_otherwise.3F

Note: Although out of print, Peopleware can be found online as a PDF, or purchased used for around a hundred dollars.

Update: Look how far we have fallen--a friend sent: "In the '60's my father took me through his insurance company offices after hours. Most of the desks were in open bays. Then we came to the computer area and he pointed out the leased IBM 360/30. Nearby there were several special rooms along the wall with doors and glass walls. I asked why some of the desks were sealed off like that and he told me that the programmers needed quiet places to work without interruption because it was so important that their programs be correct. Your article brought back that memory."

Scrum Is A Flow-state Interrupter

Overall, Scrum is useful.

But the Daily Interruption is an abomination.

First of all, because the Daily Interruption is supposed to be held every workday, it interferes with no-interruptions days.

Second, the Daily Interruption serves no purpose.

I realize this is heresy, but look at what is supposed to happen in the Daily Interruption. Every team participant is supposed to answer three questions:

1. What have you done since yesterday?
2. What are you planning to do today?
3. Is anything blocking you?

The first two questions can and should be replaced by emailed status reports. Why waste time telling me something I can read (if I care, which I don't)?

The third question is even more asinine. Why would a programmer wait an average of 12 hours to bring up something that's blocking them? Shouldn't they deal with the problem right away?

If someone comes to a Daily Interruption to kvetch about a blocker, my question to them is always why haven't you dealt with this already, dummy.

Because the Daily Interruption serves no purpose, requiring programmers to attend it is fiduciary irresponsibility.

The Daily Interruption was invented to solve communication problems on dysfunctional teams. If a team is not dysfunctional, the Daily Interruption is make-work. Wasteful, flow-killing make-work.

But just try convincing a ScrumMaster that the team can do without the Daily Interruption. They've been to ScrumSchool, you see. They're ScrumCertified.

Except they didn't read the whole book. If they had, they'd know that Agile methodologies (of which Scrum is an instance) support Method Tailoring. And Method Tailoring allows a team to modify a methodology to fit the needs of the team and the project the team is working on.

In other words, a team can, with the blessing of Agile, tailor Scrum to eliminate the Daily Interruption.

As a compromise, if a team simply must have the Daily Interruption, at least only have it on the three days of the week that are already contaminated by other meetings. Leave the no-interruptions days alone.

Because our team has enlightened management, the Daily Interruption is not scheduled on no-interruptions days, and attendance is optional on the other three days.

Mandatory Meetings

Unless required by law, there should be no such thing as a mandatory meeting.

The best way to get people to attend a meeting is to make the meeting worth attending.

Mandatory meetings are particularly annoying when they're supposed to be "fun" (for example, a team-building offsite). Mandatory fun is an oxymoron.

Feedback On Non-recurring Meetings

Because meetings are flow-state interrupters, companies should have a process for improving the quality of all meetings, including non-recurring meetings.

After every non-recurring meeting, a survey should be sent to everyone who attended the meeting, asking some questions:

• Did the meeting start on time?
• Did the meeting end on time?
• Do you understand the purpose of this meeting?
• Do you feel that this meeting met its stated purpose?
• Based on the average fully burdened salary of the attendees, the cost of this meeting (not counting opportunity cost) was $<put cost here>. Do you think that cost was justified?
• Is there any information communicated during the meeting that should be communicated by some other means (for example, in email)?
• Which of the following actions would have improved the meeting (check as many as apply)?:
• Add ______ to the agenda.
• Remove ______ from the agenda.
• Change the allocated time to ______.
• Reduce the number of attendees.

Meeting ratings should be considered in employee's annual reviews.

Winnowing Recurring Meetings

Whenever someone takes over an IT department, the first thing they're supposed to do is cancel all reports.

The thinking is that many reports are leftovers nobody cares about anymore, and shutting them off is the best way to find out which ones matter to someone.

Have you ever found yourself in a recurring meeting where you wonder what the point of the meeting is?

That meeting is like a zombie report. Nobody really needs it anymore, but there's no process in place for getting rid of the meeting. It just lurches along on inertia, wasting everyone's time.

Because meetings are flow-state interrupters, companies should be proactive about getting rid of recurring meetings nobody needs anymore.

Every recurring meeting should have to interview for its job on an ongoing basis.

After every recurring meeting--or at least quarterly--a survey should be sent to everyone who attended the meeting, asking some questions:

• Did the meeting start on time?
• Did the meeting end on time?
• Do you understand the purpose of this meeting?
• Do you feel that this meeting met its stated purpose?
• Based on the average fully burdened salary of the attendees, the cost of this meeting (not counting opportunity cost) was $<put cost here>. Do you think that cost was justified?
• If you do not feel this meeting is justified, do you feel that it should simply be cancelled, or improved?
• If you feel the meeting should be cancelled, is there any information communicated during the meeting that should be communicated by some other means (for example, in email)?
• If you do not feel that this meeting should be cancelled but instead should be improved, which of the following actions do you think should be taken to improve it (check as many as apply)?:
• Add ______ to the agenda.
  
• Remove ______ from the agenda.
• Change the allocated time to ______.
• Hold it less often.
• Make it non-recurring (only hold it when needed).
• Reduce the number of attendees.
• Combine it with the ______ meeting.
• Reschedule it to ______ to leave a larger contiguous block of uninterrupted time available.

If a meeting fails the interview, it should be cancelled, no matter how important the meeting owner thinks the meeting is.

Constant review and winnowing of meetings can, over time, convert this:to this:If a meeting passes the interview but needs improvement, it should be improved per the survey feedback.

Meeting ratings should be considered in employee's annual reviews.