a new app pricing model

Personally, I don’t like the idea of “in app purchases” which seems to be the norm these days in the current app pricing model. You get the app for free, try to use it and then find out that you can’t save your results unless you pay the author for this feature. If you’re like me then you usually feel like they’ve wasted your time.

I would suggest that a better model is how we now buy music.

Changes in the recording industry

You used to have to purchase the entire album just to get a single song, that was just how things were. If an artist or band had one killer song that was enjoying a lot of airplay on the radio and assuming that you really wanted that song then you had to pay the $12 or so for the entire album. And you just crossed your fingers that one or two of the other songs made it worthwhile.

With the advent of iTunes and similar websites, we now have the ability to sample and purchase exactly which songs we want to pay for. If half of the album isn’t worth it, you don’t have to buy all of it. If the artist only has one good song then there’s no reward for them to pad the album with a lot of junk.

A new model for app pricing

So why shouldn’t we just show our app’s prices up front instead of hiding them inside? Currently, a new customer can’t see how much of the app is crippled and how much is functional until it’s been downloaded and used. How many times have you downloaded and demo’d two or even three different free apps of the same kind, trying to find one that was reasonably useful?

What we need is a venue for selling our apps like musicians sell their songs. Theoretically, it might look something like this:

PayAsYouGo_734x466.png

More feature transparency

The biggest benefit to a model like this is that it shows the potential customer what’s included in the full program and the cost of each feature. If, like me, they’re not interested in the social connector feature then they simply don’t purchase it. You pay for what you need and nothing more.

As developers, we would distribute modules of functionality and charge the user on a per-module basis. I would suggest that features be priced differently based upon the perceived value. In fact, there’s nothing to prevent the price of a popular feature from increasing over time.

Like in the iTunes model, clicking a play button next to the feature ought to bring up a demo or screenshot of the feature in action.

crowd-sourcing your bugs

Most of us in the contracting space are interested in alternate ways of making money. Personally, I enjoy straight programming to almost any other means of earning it but I discovered something recently that looks interesting. There’s a website now that seemingly pays for finding bugs in the code of others. As programmers we are often good at spotting problems early and we’re probably the best at finding them. Troubleshooting is usually something that isn’t seen as a profit center so why not flip things and make some money doing it?

Bugcrowd.com

Enter the new website which appears to be crowd-sourcing the problem of code testing. Various companies then work with the website to outsource this task to others who attempt to identify a problem worth fixing. If they decide that it’s indeed a bug then they usually pay some form of money to the researcher.

My Anecdote

From my own limited experience, I created an account, reviewed the many offers and picked the Tesla Motors website to look for security problems. Within an hour I identified something from a third-party webtiming partner which turned out to be flagged by Microsoft Security Essentials as the Win32/Spursint.A Trojan. (Not bad for just an hour’s work, I thought.) I then wrote up my findings and awaited  a response. Someone  did respond within 24 hours.

But then the fun began as I attempted to communicate what I’d found. Since they couldn’t recreate what I’d seen they submitted the linked JavaScript to other antivirus sites which found it to be clean.

Next, I tried to explain the nature of the Akamai network of caching servers and how a local version of their server might be delivering different content than what I’d received: some get the Trojan and some do not, in other words. Again, this was falling upon deaf ears.

I then tried to convince them that development-related timing code isn’t normally pushed to production, that their build process should have groomed this out in the first place. Again, no sale. They just didn’t want to hear that their third-party JavaScript provider could have been compromised. Lesson learned: don’t waste your time twice with the same company who won’t listen to reason.

Closing Thoughts

Will I use Bugcrowd again? I like the concept. I think I had rather spend my time, though, in a more fruitful venture with a less risky return.

New wisdom: Avoid systems in which you perform labor and then someone else decides whether or not your labor deserves getting paid for. Oh, and unless you have an up-to-date virus checker you may want to avoid the Tesla website since it sometimes delivers a Trojan to your browser.

free doesn’t have to mean free

open-source  adjective  COMPUTING

denoting software for which the original source code is made freely available and may be redistributed and modified.

A lot of people seem to think that this means that you can’t charge money in an open source world.  Making the source code freely-available doesn’t mean that you can’t charge for the compiled program itself.

You might be surprised to read this GNU page on “free software”.

Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.

The word “free” has two legitimate general meanings; it can refer either to freedom or to price. When we speak of “free software”, we’re talking about freedom, not price. (Think of “free speech”, not “free beer”.) Specifically, it means that a user is free to run the program, change the program, and redistribute the program with or without changes.

The problem then becomes the one where some of us don’t have lawyers and some of us do.  The ones who don’t have lawyers probably operate under the following assumption:

  • “since I downloaded freely-available open source software as dependencies to my own software, I can’t charge for compiled code which include those”

Conversely, this might be the competing assumption by a large corporation who has lawyers and who understands the playing space better than you or I do:

  • “even though I downloaded freely-available open source software as dependencies to my own software, I can charge for compiled code which include those”

So you should be able to see how a million or so open source coders can now be taken advantage of.  They actively participate in what they believe to be a generous social experiment and yet some of the players in the space aren’t being so generous.

As coders, we need to find the means for making money somehow for all this effort.  Open source is a great concept but it feels to me like people aren’t seeing the bigger picture here, the one in which some people are making money from your free labor and at your expense.

royalty-source code

The Concept

Here, I’m coining a new term for the software development world.  Similar to open source software, royalty-source code would be widely available for download via a system like github.  Unlike open source, however, royalty-source includes a mechanism so that each coder gets paid as programs get downloaded.  This new mechanism should fairly distribute royalties based upon some sort of weighted system for each of the dependencies.

Typical Dependencies

The following tree shows a typical collection of dependencies pulled into a new Node.js program named MyNodeProgram, as an example, with the single command npm install mongoose:

  • MyNodeProgram
    • mongoose
      • async
        • benchmark + 22 other dependent libraries
      • bson
        • nodeunit
        • one
        • benchmark
        • colors
      • hooks-fixed
        • expresso
        • should
        • underscore
      • kareem
        • acquit
        • gulp
        • gulp-mocha
        • gulp-jscs
        • istanbul
        • jscs
        • mocha
      • mongodb
        • etc
      • mpath
        • mocha
        • benchmark
      • mpromise
        • etc
      • mquery
        • etc
      • ms
        • etc
      • muri
        • etc
      • regexp-clone
        • etc
      • sliced
        • etc

Doing a directory listing of your program’s node-modules subdirectory should then reveal just how much code got pulled from github with that single npm install command earlier.

Royalty Debt

Unlike open source coding projects, royalty-source coding projects add a new concept to the business model.  Royalty debt is the added virtual cost to your project with each npm install command you invoke.

If you envisioned charging $1.00 for each download of your own program and it now contains that mongoose dependency from before, you’ve greatly diluted your own code with the inclusion of this large collection of code that somebody else created.  If you created a typical Hello World program that uses a MongoDB database and assuming that you only add a few lines of your own code, then you might only get $0.01 of that $1.00 download royalty and everybody else would get the remaining $0.99 of that sale.  Without that mongoose inclusion, it would be unlikely that anyone would want to pay you $0.01 for your code, at least in theory.  You might then accept this 1% ratio as what it takes to make money.

Instead, you might start to rethink your entire program from the ground up.  If you could remove the mongoose dependency and store your data in a simple BSON object instead you possibly could drop that dependency completely and the royalty debt it incurs.  Assuming that you no longer had any other dependencies and people are still happy to pay the $1.00 price tag, 100% of that is now yours to keep.

One big benefit to this concept of royalty debt is that it should incentivize coders to review that stack of dependencies to look for anything that’s been included and yet which doesn’t add much value to the overall project.  The coder then should remove any unwarranted code to lower the bloat effect we often see in open source projects.  Smaller code is often better code.

Pay the House

Obviously, whoever is the new github provider will charge a commission of some kind for each download.  The download price minus the commission equals the total royalty to be split up.

Hopefully this system would include balances which would allow someone with existing credits to then use them to download other code.

Royalty Distribution

Presumably, a value system would be in place which weighs each dependency against the parent program’s code with some kind of fair distribution model.  As in the above Node.js example, the benchmark code appears at least three times as a dependency and should then get a bigger piece of the pie, so to speak.

New Tools

Given that we’d now have royalty debt to think about before adding a new dependency to our project, we should have some tools to quantify that cost.  In theory, you’d run the npm install command with an extra argument which quantifies that module’s package.json dependency list.  Let’s say that you might run the following command from your MyNodeProgram folder:  npm install mongoose --cost

At this point, npm might indicate…

mongoose @4.3.5:  Cost=$0.99/$1.00

Note that this is assumed to be a guesstimate at this time since your own program’s few lines of code were compared to the collective code and dependent modules of mongoose to return this ratio.

As a coder, you now have a build-versus-buy decision:  1) build your own database code instead or 2) expect to pay for mongoose (and dependent code) with each sale/download of your own code.

Pay the Piper

Obviously, it wouldn’t be fair to the coders of your own dependencies if you under-valued your own program.  If you decided to charge only one cent for your Hello World example above with all those dependencies, you’re distributing someone else’s code for a small fraction of what it would be worth otherwise.  In this system each module author should be able to define a minimum cost for their library.  As this code gets included into parent projects they should honor this requirement.

The benefit of this minimum cost feature is that it will gradually increase the cost of increasingly-larger code.  If the total minimum cost for the mongoose module is $0.33 then the next author must charge a minimum amount which factors this into the total download price.

Final Thoughts

So why should we bother with a royalty-source code system when open source seems to be working fine?

  1. We’re not getting paid to create software
  2. Everybody expects us to be responsive to their own needs (fixing bugs/issues) without considering that we normally expect to pay for services rendered
  3. Corporations are using open source code as a means of not paying software developers
  4. Other than a virtual tip jar, there doesn’t appear to be anywhere within the open source system where the coder gets anything for their efforts
  5. It costs a lot of money to pay rent, to eat and to otherwise afford a working computer and Internet connection as a developer

open source

open-source adjective COMPUTING

denoting software for which the original source code is made freely available and may be redistributed and modified.


This is a big change for me, having made a career over the span of half my adult life as a software developer and usually getting paid for doing that.  In the U.S., here’s the timeline for software development:

  1. 1980-1985:  In its infancy, the earliest software developers made software for the novelty of it.  Nobody fully understood the value of computers and this software so a market didn’t really exist yet.  There wasn’t a lot of money to be made; it was a hobby and we knew it.  This early period ended in the mid-80s when business started embracing these solutions and were willing to pay for them.
  2. 1986-1999:  In its heyday, software developers during this next period would flourish.  The advent of the Internet and website solutions largely fueled this feeding frenzy.  Programmer salaries climbed to the point of six-figures for someone good.
  3. 2000-2013:  Abruptly in 2000 at the end of Bill Clinton’s last term, a huge number of software developer jobs were suddenly outsourced to foreign countries, chiefly:  India, China and Russia.  The U.S. still hasn’t fully recovered from the job losses sustained but businesses have learned that not all outsource promises actually pay off.
  4. 2014-current:  The current trend appears to be a movement away from the (licensed) Microsoft and Mac OS operating systems to any of a number of UNIX-based systems and especially browser-only software and phone applications.  Further, this trend continues with this “no fees” mentality by abandoning earlier licensing models completely.

From a personal-reward standpoint, the open source initiative has returned full circle to our earliest days.  You make software but you don’t do it thinking about the money.  Perhaps you hope that things will just work out and some money will land in your lap somehow.  Maybe this project will lead to a paid gig somewhere, who knows?  I think most young programmers are doing it to beef up their résumé and little more.

I think I would caution U.S. programmers, though.  It’s good to make free software and to make it available to other good people who do the same.  Please know, however, that there are corporations right now who are using open source to avoid paying software developers for their livelihood.  Corporations are using someone’s free labor as a means of saving costs.  I don’t think this is what the open source founders had in mind.

Corporations are using someone’s free labor as a means of saving costs.

Is this fair?  Having been a programmer for over three decades it doesn’t feel like it’s a fair playing field right now.

In order to compete in today’s market it seems like you need to program in the world of open source.  Given the current nature of open source this means that there are others who aren’t similarly contributing and yet who still enjoy the fruit of your free labor.  They’re making money and you’re not.  That’s not Capitalism, that’s essentially Feudalism.

The cost of maintaining a computer, a good Internet connection and keeping current on the latest software costs money.  Rent is expensive especially in the tech-savvy areas of our country.  The economy already is devaluing U.S. labor across the board and has done so for a little over ten years now.  In light of all this I have to ask the rhetorical question:

Why are we now giving away our high-tech labor for free?

It strikes me as a bad strategy.  Corporations outsourced a decade ago and then, presumably, learned from their lessons that outsourcing doesn’t produce quality code.  And now that we have this golden opportunity back young U.S. programmers have decided to enter the market without being paid for their labor, further devaluing the cost of software for everyone.

We can rightly blame corporations for being too greedy over the last decade.  But we then must blame ourselves if we decide to work without being paid as an industry.  Are we so afraid of the competition of outsourced foreign labor “on the cheap” that we have to fall suit and do the same?

But we then must blame ourselves if we decide to work without being paid as an industry.

If you want to contribute to the open source initiative (as I am) then I’d strongly suggest that you don’t give everything away for free.  Seriously guys, it’s time U.S. programmers found a better compromise with the consumers of software so that we can better afford to live here.