[ba-ohs-talk] Re: Rethinking Licensing
As always, I toss out a few crumbs and Paul ships back a loaf of well-baked
bread. And, then, Eric steps in with an interpretation of my crumbs that's
much closer to my view that is Paul's interpretation. (01)
I may have created the opportunity for misinterpretation myself by using
the term 'micropayment' which, as I understand the origins of the
transclusion process, was, indeed, a *per-use* charge, with all the
attendant concern about costs and so forth. Indeed, I wasn't thinking
about that particular brand of micropayment, rather something much closer
to what Jason Hunter does and which Eric describes below. The software is
free; essentially take it and have fun with it, learn what you can, and so
forth. But, there is this simple financial incentive to "join the club"
and add value to it. I did not intend that there be an interpretation of my
thoughts that each click would cost something, though I think I can see how
that interpretation got license. (02)
At no time am I attempting to add a cost to the OHS. But, at the same
time, I am, in some sense, stepping back from the '*open source* concept
and moving in the direction of the *free software* movement, but with the
twist that my *free software* is always free until you decide to sell it,
at which time, I'd like a tiny fee for each copy and I'll share that
revenue with those who have made my work possible. I might even be willing
to negotiate volume discounts, and so forth. (03)
My motivations are related to my experience working with kids in high
school in a Java programming course. I tend to think that if kids saw a
nearer-term opportunity to turn their work into beer <strike that> soda
money, they might take the learning exercise more seriously. My
motivations are also related to my personal desire to take OHS-like
technology to the world's classrooms, naturally, by way of the Web. There
needs to be a way to turn that activity at once into a value proposition
(online courseware in which kids all over the world can share in projects)
and a financial proposition (opportunity to distribute software within a
revenue generating system). (04)
Paul's comments on having licenses evaluated, on securing 'buy-in' by those
you really need to buy in, are well taken. My hunch is, however, that the
GNU Linux experience making it into enterprise and into schools shows that
such things are possible, particularly if there is a need. The school with
which I am involved has a CTO who is MS-certified, so cracking that entity
is only going to happen when MS stops giving away their product or vendors
slow down on the massive discounts, and the school finally has to pay the
true license costs associated with the number of copies of Office they are
using; the bean counters may yet prevail. Hard to tell, however. (05)
Eric's comment that this scheme turns each of us into a publisher nails
it. That, I think, can serve as a foundation for a financial ecosystem. To
explore that notion a bit, consider that I happen to sell widget A and, no
matter what you sell A+B (where B is your widget that uses A), I want, say,
$1 for A. Theoretically thinking, your widget B could be the one widget
that everyone wants and you get to sell it for $500. I still get my $1,
and I'll pass some portion of that along to those who made my work
possible. In theory, you will do same in your accounting process. And, I
imagine that if your marketing projections suggest that you expect to sell
a million of your widgets, I should expect you to come and start arguing
for a reduction in my $1 fee. Frankly, I'd like to have such *problems*. (06)
Don't know if that cleared anything up. Hope not. (07)
Cheers
Jack (08)
At 04:54 PM 5/13/2002 -0700, you wrote:
>Paul Fernhout wrote:
>
> > === on micropayments ===
> >
> > I like your effort towards rethinking. I especially like your question
> > at the end regarding the BA value proposition -- that is a good question
> > to always revisit periodically for any effort expecting support.
> >
> > However, sorry, I don't think micropayments are the answer. See:
> > "The Case Against Micropayments"
> > http://www.openp2p.com/pub/a/p2p/2000/12/19/micropayments.html
> > The article discusses several reasons, the biggest one is that the user
> > cognitive overhead of dealing with micropayments is too high. A
> > transaction might cost a fraction of a cent, but it costs you time and
> > attention to think about it (even to decide whether to click or not,
> > knowing you need to pay), and that makes every micropayment
> > fundamentally expensive. The article also suggests several old
> > alternatives (Aggregation, Subscription, and Subsidy) to micropayments.
>
>When micropayments revolve around *use*, I agree that they are
>doomed. No way do I ever agree to have something around that is
>going to keep charging me forever. The main issue is that I have no
>control of my expenses, because I can't keep track of all the little
>things that are nailing me all the time.
>
>But when micropayments consist of revenue-sharing -- so that they
>only occur when a purchase decision is made, they have a chance
>of succeeding.
>
>In that case, the end-user never even knows about them. Done right,
>the seller can even afford to ignore them, because some fraction of
>revenues are diverted as royalties before the income is even seen.
>
>Assuming that the parameters are acceptable beforehand (for example:
>10% of whatever I charge is going to the 10 or 100 developers of the
>APIs I use) then I don't particulary need to know or care to know how
>those royalties are divided. I just know I'm getting 90% of whatever I
>charge, and things are relatively simple.
>
>That kind of situation turns each of us into a "publisher" who generates
>some code on our own while incorporating other code. Any time we
>sell something, we pay royalties. If we give it away, then it goes out for
>free.
>
>There is still a lot of room in this equation for problems to arise, though.
>For example, developer of Module XYZ may require that:
> a) You can't sell any product that uses it.
> b) You can't give away any product that uses it.
> c) If you sell it, it gets 1% of the revenues, regardless of how
> much you charge.
> d) If you sell it, it gets $10 a pop, regardless of what you charge.
> e) If you sell it, it gets 1% or $10, whichever is greater.
> f) If you sell it, it gets 1% or $10, whichever is less.
> g) You have to charge at least $x for any product which uses it.
>
>All of these options affect how widely the module will be used, and
>how much revenue it may generate. Figuring out the best strategy
>for the module developer is something that requires thought.
>
>By the same token, the integrator needs to figure out their best
>strategy, too, based on the availability, functionality, reliability,
>and pricing of various modules at their disposal.
>
>This is basically SW development as it occurs today, only with
>automated revenue sharing that is confined to the point of transaction.
>
>Such micropayments would not only be acceptable, but also highly
>conducive to code sharing and reuse. Stuff would basically be free
>for use, but anytime you managed to make a buck, people who
>developed code you use would get a bit. That would provide
>both incentive and the wherewithal to do more.
>
>If such a marketplace provided the means for making software
>available, then a developer could spend less time thinking about
>the mechanics of distribution, and more time thinking about their
>designs, which would also be to the good. It would help to
>promote cottage industries, because it would reduce much of the
>staff you need to carry on a business. (Support and marketing
>staff would still be needed, but sales and distribution staff could
>be largely eliminated.)
> (09)