Ransom Software for Fun and Profit
 by Brian Shire, in Editorials - Sat, Nov 23rd 2002 00:00 UTC

Users have three main goals in mind when considering software: support, freedom, and quality. Users may not directly recognize these attributes, but they are relevant to every software decision. In this paper, I'll cover these three objectives and explain why releasing software under a ransom system may be a good alternative for some software projects.

Goals of Software

Support

The first concern of users is support. Support is typically needed not only because of problems with the software itself, but also because of problems with user understanding. In today's market, the illusion of support is more typical than real satisfactory support. Users will often make a purchase decision based on this illusion because it provides comfort similar to an insurance policy. They believe support will be there if they should ever need it.

Freedom

Users want the freedom to use software to suit their needs. The recent upsurge of Open Source software has demonstrated this need. Users usually refer to "buying" software when, in fact, they are leasing software. Many software companies impose many restrictions on the use and distribution of the provided software. Although personal users typically violate these agreements without penalty, companies are forced to play by the rules. It's important to note that better freedom will also provide better support. Anyone with access to the source can support and fix the software. Without such access, it would be difficult at best to provide any support to existing customers.

Quality

Last, but not least, we want to consider quality. What point would there be in support and freedom if the software didn't perform the way we wanted? There are a few different perspectives on quality. The developer has one point of view, the business another, and the end user still another. The users' is the most relevant standpoint, simply because of their numbers. Bad quality can usually be corrected with good feedback from the end user.

Enter the Ransom System

Up to now, we've covered some of the "mile high" views of software development. Next, we'll discuss the real purpose of this paper: The ransom system.

Overview

The Ransom license was originally created by Theoretic Solutions, a public think tank which works for the betterment of technology, business, and politics. In order to properly understand the ransom system, it's helpful (at least for this author) to think of all software as information, rather than as tangible products. Once you consider software in this light, the meaning of product purchases becomes different. Here are some important points to consider about the sale of information:

1. The sale of information does not include charges for raw materials, and therefore is difficult to quantify. You can't justify pricing with the costs of raw materials such as timber, oil, or silicon. It relies directly on how much the buyer is willing to buy for and how much the seller is willing to sell for.
2. Information is easily transferable. The more parties that have access to information, the more likely it is to spread and lose value. It is therefore of greater interest to sell at a higher price to fewer parties rather than at a low price over a long term.
3. Any attempts on restriction of distribution and use will fail in the end due to unrealistic costs of enforcement.

The ransom system aims to alleviate some of the problems with current software release systems. Typically, software is either sold on a per customer basis, with highly restricted use and distribution terms, or given away freely to the public. The first treats the customer unfairly and the second treats the developer unfairly (in most situations). The ransom system allows developers to release Open Source software, but get compensated for it at the same time.

Ransom Properties

Ransom Releases have the following properties:

A total ransom amount to compensate for all development.

Once this amount has been paid to the developer, the software is released to the public under an OSI/FSF compliant license.

Smaller payment amounts.

These may be accepted in exchange for limited use copies of the software. These payment amounts accumulate and go towards the payment of the total ransom amount.

A dissolve date.

This guarantees the release of the software by a specific date, regardless of payment.

Support

• Because the ransom typically only covers development, services can be sold to support the project. This cuts initial costs and keeps the users paying for only what they need.
• If the developer drops the project, it can be picked up by other interested parties.
• Because the developer is compensated, he/she is more inclined to offer support and documentation for the project.
• The final release to the public allows anyone to offer support.

Freedom

• Users are not charged for the number of copies, users, processors, or data transfers. This creates a fair market in which customers are not charged for the size of their company or any other irrelevant factor. (The size of a company imposes no additional costs to the developer.)
• The final license is Open Source, offering much more freedom than typical commercial software.

Quality

• Users are more likely to provide feedback on Open software that they've paid for.
• Developers are more inclined to provide quality and listen to feedback when they are being compensated for time spent on a project.
• If the developer offers discounted or free access to code contributors, companies may be able to recoup any additional development costs made to the software.

The Technology Ransom Network

The Technology Ransom Network has been set up at http://ransom.tekrat.com/ to assist developers with the use of a ransom model.

• The ransom is handled by Tekrat Labs, not the developer, to help ensure fairness.
• Accounts are free to set up; the only costs are credit card transaction fees taken out of payments
• PayPal is used, so it's easy and free to set up.
• Account creation, payment, and access to the project are handled; developers just upload releases as they become available.

The Technology Ransom Network makes it easy to release quality software. Developers who want to try a new releases system can easily take it for a test drive by creating a new account and placing a single version up for ransom. If they like how the system works, they can ransom another version. If not, they simply continue to release the software as usual.

Conclusion

The ransom system shares many common roots with today's Open Source development, but tries to enhance it. Ransom software creates a fair and stable environment for developers to work. It also keeps the users in mind by not restricting their use or requiring unfair compensation. It's hoped that this can directly or indirectly bring about positive action in the software development community.

Author's bio:

Brian Shire is a software developer currently working on his own projects at tekrat.com. Outside of computers, he plays the trumpet and scuba dives. His homepage is at http://www.tekrat.com/shire/.

T-Shirts and Fame!

We're eager to find people interested in writing articles on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an article gets a t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let jeff.covey@freshmeat.net know what you'd like to write about.

[Comments are disabled]

Referenced categories License

 Comments

[»] new place for bounties
by rug - Aug 29th 2005 09:15:05

dont know if anyone still cares, but lets try to centralize all the software bounties.

One place to post 'em , one place to collect 'em, (one place to form commitee, and in the darkness bind them)

have a look at bountycoder.org
anyways....

[reply] [top]

[»] The methods of payment
by Teemu Voipio - Dec 13th 2002 21:04:39

There is one difference between closed and open software that isn't covered here. It's the ease of getting open software.

Say, I want a new usenet reader, because I don't like my old. Now, I search Freshmeat. Then I find few candidates. I can test them, and start using the one I like the most. All of this takes me about 15 minutes average.

For closed software I'd have to find someone that has the product, ask him to let me test his installation, then find a store that sells the product. If I want to test say 20 different programs, it easily takes more time than writing a new one with those 5 features I need.

Paying for software in the net would be nice, but usually you have to fill n forms to do anything special in the net. Now, I'd love to send few bucks (maybe $10) for a decent newsreader (provided that it means I can get support if it doesn't work). What web lacks is quick and secure anonymous payment. If I could have the newly installed newsreader tell my digital-wallet that "you have exhausted the 30 day test period, you need to pay $10 to the developer" and then the digital-wallet prompt me to accept the payment, I'd be more than willing to pay.

It's the same thing with real life. If a friend asks me for 1 euro (I live in Finland), no problem if I have a coin. But if I don't (even I had plenty of money with me) I'm unlikely to bother.

Another problem is feature bloat. Now, if I need feature X and can't hack it myself for various reasons, it would be nice to send another $5 or so for that feature. But if, to get that feature, I need to buy software that costs hundreds of bugs and contains hundreds of features I don't need, I'm not interested.

Now, I write software myself. I'd love to sell some. But I'm not interested in getting myself into a bureaucrazy hell, so I just write "This software is released under GNU GPL" and let it go. So much more simple.

--
-teemu

[reply] [top]

[»] Re: The methods of payment
by A Visitor For First Time - Dec 16th 2002 14:12:40

Yes I agree with you that convenience is important. I have had success in finding new software using the free trial download model (30 day trial, etc., or unlimited trial with ads, etc.).

If the software is good enough, after the trial period I am then willing to undertake the payment transaction.

Maybe this gives the developer some incentive?: the software has to provide enough benefits that I am willing to complete the payment transaction instead of un-installing.

In any case, I have found the trial period to be just as easy as with freeware.

I believe there are clearinghouses for "shareware" payments that facilitate purchase and sale. Presumably the good ones make it easy for the purchaser and take the burden off of the software publisher.

[reply] [top]

---

[»] Re: The methods of payment
by Teemu Voipio - Dec 16th 2002 14:45:12


> Yes I agree with you that convenience is
> important.
>
> I have had success in finding new
> software using the free trial download
> model (30 day trial, etc., or unlimited
> trial with ads, etc.).
Shareware is good, the problem is that it's often hard to find a way to pay for a program if you don't own credit card and live outside USA.

Another thing is that too many programs only allow "limited trial" which is useless, if the features you need happen to be only in the purchasted version.

Say, for example one music tracker offers a wave output plugin if you register it. But without the plugin I am unable to find out if it produces sound that sounds good when mixed with something else.

Winzip is one of the programs that have good shareware solution (though I don't use Winzip myself as I'm Linux user). It prompts you with a notification, which is a bit annoying but that's it's purpose. Worth noticing here is that IF it stopped working, it would suck (maybe you don't have money just now or some other problem that delays you from obtaining the registered version), it offers all features ("this feature is only in the registered version" gets an application uninstalled or more likely cracked at once), you don't have to reinstall registered version, and there is no fscking delay in the splash screen (although you have to click a button).

I also like the model where you can test the full version for free, but if you are using it commercially you have to buy a license for it. There's really no point in buying Oracle to test if it works for your database needs, and it seems Oracle has realized that.

Another nice thing with Oracle style distribution is the following: now, I used to work for a company that has companywide license for Oracle. The problem is when you need to install a client (or a dev server) somewhere, you have too options, either get the CD from someplace (Oracle netsite, at least that time), or call the local service desk to get them install it and wait n days.

Latter is not a solution if your laptop with your oracle install happens to be home, it's 20:00 and the damn database is breaking more every second.

Ads are ok with some software, but often they really don't work. Example is Opera. Now, I like to see a lot of the page on my screen. I have even the bookmarks row in Mozilla disabled (to Mozdev: could you please move home button back to the same row with address). Now, I wanted to see home much screen estate I can get with Opera. Impossible. The ads are there making it impossible.

And I sure ain't using a webbrowser that takes half of my screen, and not paying for one I haven't tested a lot (to see if it really works with what I need).

--
-teemu

[reply] [top]

---

[»] Re: The methods of payment
by Raven Morris - Feb 11th 2003 16:22:55


>
> Ads are ok with some software, but often
> they really don't work. Example is
> Opera. Now, I like to see a lot of the
> page on my screen. I have even the
> bookmarks row in Mozilla disabled (to
> Mozdev: could you please move home
> button back to the same row with
> address). Now, I wanted to see home much
> screen estate I can get with Opera.
> Impossible. The ads are there making it
> impossible.
>
> And I sure ain't using a webbrowser that
> takes half of my screen, and not paying
> for one I haven't tested a lot (to see
> if it really works with what I need).

I am very conscious of my screen estate as well. I usually like to view one window at a time, maximized. That way I can view much more of the document, with no distractions. ICE Window Manager allows me to easily use keybindings to flip around instantly to my various desktops, load up apps and maximize/restore ... and use full-screen (as of the new versions of ICE).

That said, I always have a copy of Opera (Ctrl+Alt+O) open on desktop 2 (Ctrl+Alt+2) set to full-screen mode (Alt+Enter). I do not find the advertisement at all intrusive. Sure if it wasn't there I would only have the status line in the top, and no button bar (I don't actually use the buttons, only mouse gestures or keyboard commands).

Anyhow, take a look at my screenshot, I think my screen real estate is quite fine. This is the computer I use at work: Debian, PIII, 512MB, 1024x768, my home machine is running: Slackware, Thunderbird 1.1Ghz, 160MB, 1280x1024 -- where the add banner is even less obtrusive.

I personally find the user interface of Opera vastly superior to what else is available in the browser market, and it is continually the innovator of things I just can't live without: MDI/tabbed interface, mouse gestures, menu of common options for enabling plugins, graphics, css, java, user agent, etc., nicknames and a plethora of others.

As far as closed-source projects go, I couldn't be more impressed with Opera. They always have listened to my complaints and suggestions, and have implimented many of the features I have requested. Not to mention they oppose monopolistic companies like Microsoft.

G'day.


--
"Time flies like an arrow. Fruit flies like a banana." -- Groucho Marx

[reply] [top]

---

[»] Re: The methods of payment
by Raven Morris - Feb 11th 2003 16:37:09

Oops, I forgot to put a link to the screenshot in the last post, heh.

--
"Time flies like an arrow. Fruit flies like a banana." -- Groucho Marx

[reply] [top]

---

[»] Market Distortion
by A Visitor For First Time - Dec 4th 2002 13:40:40

One of the problems mentioned in prior comments is how to set the value of a given project. There were comments about how the developer could not be trusted to set the value, etc. It seems clear from these comments that the Ransom system distorts the market.

Why do I say this? Because little or no consideration seems given to the market as the means for establishing the value of the project.

Consider this also: as a software developer, suppose that I create a product that is very high in quality and very useful to very many people over a long time period.

Why would I not want to enjoy being compensated commensurate with the value that I have brought to the community?

Ransom appears to create a short-circuit at the level of the pre-determined ransom compensation.

For those seeking intellectual challenges, technical challenges, and improvements in the fairness of software I would suggest considering approaches to help improve efficiency of the market.

As a user this means voluntarily paying fairly for the benefit I receive (not being "robbed" by mopolistic practices, miscommunication of product features, and so on); and as a developer this means being rewarded for the value of what I bring to the community.

For this time, I would suggest that projects that introduce systematic distortions in or otherwise interfere with the exchange of benefits / rewards are, ultimately, really rather uninteresting.

[reply] [top]

[»] Why worry about code visibility?
by jomasseyfrenard - Nov 25th 2002 20:35:27

Many of the articles here are agonising about the information (code) gaining or losing "value" through the transaction. This is irrelevant. Who cares? The developer wants to develop. Users of his code want a new feature. He develops it, they pay him.

The point is that the developer is getting paid for doing useful work. The code could be open source and available right throughout the process, or only at the end. Doesn't matter.

Selling licenses sours the relationship between user and developer, because of the zero unit cost of software. Distributing entirely free software sours the relationship between the developer and his landlady.

The Ransom Model is a very good way to engage in a more productive, mutually beneficial relationship.

Over the last year we've developed an application which supports the whole process - managing user requests, issuing proposals, receiving votes and comments, a review process, surveys, news, etc. etc. - www.rap-x.com .

--
Jo Massey-Frenard

[reply] [top]

[»] Diffrence from SPP?
by Aaron Denney - Nov 25th 2002 05:39:54

How exactly does this differ from the Street Performer Protocol? And if that hasn't caught on in four years, why should we expect this to? I'd love to have someone give it a try, mind you, but I don't expect much to come out of it.

[reply] [top]

[»] Ransom == Bounty
by Wes Biggs - Nov 23rd 2002 22:34:51

While it might work for "code it and leave it" projects like games, it won't work for most ongoing software projects. Let's say there was a ransom for Apache 2.0. Great, the developers make some money, the world gets a release. Now they want to work on 2.1 and demand another ransom. Screw that, say the users, I've got Apache 2.0 (under the Apache license, no less) to hack on, I'll make my own 2.1.

The ransom model works if no one's willing to do the work for less (or nothing) -- making it essentially the same as a bounty system in those cases, and futile otherwise.

[reply] [top]

[»] Re: Ransom == Bounty
by shire - Nov 25th 2002 23:22:17

I agree that this may be a tender point for the ransom model, however I think the real question about sequential ransoms is how much would the user be willing to pay to get the next version. There are a great number of factors here though, the amount of the ransom, the range of the version ie: ransom may be for the entire 2.x branch or 2.1-2.5. If we are 'leap-frogging' the ransom versions. Also the ransom should be considered paying for work done. If someone else can/will do it for less than that's just capitolism at work.

[reply] [top]

---

[»] Maybe get the money upfront?
by tryggth - Nov 23rd 2002 18:49:33

The ransom model is interesting. Maybe the below variation would get commercial support.

Produce code under contract with the provisio that the code would be GPLed at date X. However, investors get license rights prior to date X understanding, of course, that the code they are using will be GPLed on X. Commercial interests could aggregate their money to get release quality prior to X. The more the commericial money, the longer the time between stable release and X during which the commercial interests have a strategic advantage over non-consortium competitors.

The upshot of it all is that the code gets funded and finished by time X perhaps quicker than it would without the limited monopoly granted to the funders.

Actually, I've seen this work in a slightly different context.

Regards,

tryggth

[reply] [top]

[»] Re: Maybe get the money upfront?
by jasoncook - Jan 23rd 2003 09:21:49


>The more the
> commericial money, the longer the time
> between stable release and X during
> which the commercial interests have a
> strategic advantage over non-consortium
> competitors.
I'm not sure I'm willing to trust this type of strategic avantage. Those with money decide they want to add proprietary code and features that are optimized against interoperability and are not platform independent. The ransom license is changed to allow it because the developers don't want to lose funding. What happens then? The rest of us who live by the GPL are left with nothing.

(I'm not saying that all developers would sell out, but surely some would.)

[reply] [top]

---

[»] Pyramid Escrow
by Lion Kimbro - Nov 23rd 2002 13:37:45

You may also want to consider a pyramid ransom system.

Ex: I build a computer game under ransom. I use SDL2 and GTK+3, two libs both under ransom.

That's okay, because we all use ransom licenses that feature conditions for "other ransoms", describing how the ransom interacts with other ransoms, and they all agree.

When someone pays $50 for the shareware game, then $5 is assigns to SDL2, $5 assigns to GTK+3, and $30 assigns to the devs. (These values are chosen because they are convenient, not because they are realistic.)

Three interesting things can happen:
A) The ransom for a support lib is met first.
B) The ransom for the whole package is met first.
C) The ransom reaches an amount that can pay off a support lib and the whole package simultaneously.

(B) is easy: Pay the dev and agent, and then the escrow info for the lib's go to their respective agencies.

(A) is a little trickier: the support lib money is not necessary, so it contributes to the whole package. WHOMP! That's a lot of money at once. However, this is unlikely, because it is dumb: why wait for lib-A's ransom, when you can ignite it before-hand?

A game is ransomed for $100,000, $20,000 assigned to lib A, $20,000 to lib B, and $60,000 to the dev and agent. At the moment, $90,000 has been collected..! Pro-rata, that's $18,000 lib-A, $18,000 lib-B, and $54,000 dev/agent.

However, at the moment, lib-A's ransom, at $250,000, is just $1,000 away! Look, we've collected $18,000 lib-A; If $1,000 paid, that's $17,000 excess..! We only have to collect $80,000, and we already have $89,000 (paying 1K to lib-A). We're already done!

The leftover portion is divided between agent, dev, and contributers according to some previous agreement.

The ransom for lib-B is assigned to lib-B. The game still collects $5.00 per user to contribute towards it's ransom until it is met. But $5.00 is far cheaper for the game than $25.00, and with liberated code out there, paid for, using lib-B, it is now better documented and understood.

There are a lot of ways to work this.

Perhaps lib-B's authors are willing to lease a binary distribution license to the agent until it's ransom is met. The game agent bonds with lib-B's agent for an amount, or automatically delivers ransom as it is accrued.

Perhaps the conditions for lib-B are based on minimums, not stated values; ex: "minimum ransom contribution is %10."

You could pool ransoms: If 10 groups are ransoming against lib-B, lib-B needs $50,000, then you can pro-rate accross the 10 groups as soon as their total for lib-B meets $50,000. Very fluid, very fast.

[reply] [top]

[»] Re: Pyramid Escrow
by Don Hinshaw - Nov 23rd 2002 20:15:15


> You may also want to consider a pyramid
> ransom system.
>
> Ex: I build a computer game under
> ransom. I use SDL2 and GTK+3, two libs
> both under ransom.
>
> That's okay, because we all use ransom
> licenses that feature conditions for
> "other ransoms", describing
> how the ransom interacts with other
> ransoms, and they all agree.
>
> When someone pays $50 for the shareware
> game, then $5 is assigns to SDL2, $5
> assigns to GTK+3, and $30 assigns to the
> devs. (These values are chosen because
> they are convenient, not because they
> are realistic.)
>
> Three interesting things can happen:
> A) The ransom for a support lib is met
> first.
> B) The ransom for the whole package is
> met first.
> C) The ransom reaches an amount that can
> pay off a support lib and the whole
> package simultaneously.
>
> (B) is easy: Pay the dev and agent, and
> then the escrow info for the lib's go to
> their respective agencies.
>
> (A) is a little trickier: the support
> lib money is not necessary, so it
> contributes to the whole package. WHOMP!
> That's a lot of money at once. However,
> this is unlikely, because it is dumb:
> why wait for lib-A's ransom, when you
> can ignite it before-hand?
>
> A game is ransomed for $100,000, $20,000
> assigned to lib A, $20,000 to lib B, and
> $60,000 to the dev and agent. At the
> moment, $90,000 has been collected..!
> Pro-rata, that's $18,000 lib-A, $18,000
> lib-B, and $54,000 dev/agent.
>
> However, at the moment, lib-A's ransom,
> at $250,000, is just $1,000 away! Look,
> we've collected $18,000 lib-A; If $1,000
> paid, that's $17,000 excess..! We only
> have to collect $80,000, and we already
> have $89,000 (paying 1K to lib-A). We're
> already done!
>
> The leftover portion is divided between
> agent, dev, and contributers according
> to some previous agreement.
>
> The ransom for lib-B is assigned to
> lib-B. The game still collects $5.00 per
> user to contribute towards it's ransom
> until it is met. But $5.00 is far
> cheaper for the game than $25.00, and
> with liberated code out there, paid for,
> using lib-B, it is now better documented
> and understood.
>
> There are a lot of ways to work this.
>
> Perhaps lib-B's authors are willing to
> lease a binary distribution license to
> the agent until it's ransom is met. The
> game agent bonds with lib-B's agent for
> an amount, or automatically delivers
> ransom as it is accrued.
>
> Perhaps the conditions for lib-B are
> based on minimums, not stated values;
> ex: "minimum ransom contribution is
> %10."
>
> You could pool ransoms: If 10 groups are
> ransoming against lib-B, lib-B needs
> $50,000, then you can pro-rate accross
> the 10 groups as soon as their total for
> lib-B meets $50,000. Very fluid, very
> fast.
>
The essential flaw in this reasoning is that if you are developing software which requires a certain lib, then that lib would have had to already been finished and released, in which case the ransom would have already been paid on that lib.

Which does bring about an interesting question: If developers depend on the libs to develop software which end users will use, shouldn't the developers pay the ransom on the libs, and the end users pay the ransom on the final software product?

-=dwh=-


[reply] [top]

---

[»] Re: Pyramid Escrow
by Lion Kimbro - Nov 23rd 2002 20:59:05


>
> The essential flaw in this reasoning is
> that if you are developing software
> which requires a certain lib, then that
> lib would have had to already been
> finished and released, in which case the
> ransom would have already been paid on
> that lib.
>
This is a big problem. If the lib is licensed with an incompatable license (such as the GPL), then the lib cannot be used. Even if the lib is under under a Ransom license, but the Ransom isn't paid, it's a problem.

But perhaps the lib developers can distribute their library in binary form, until the ransom is met..?

[reply] [top]

---

[»] Just one thought...
by KDan - Nov 23rd 2002 12:16:39

# Information is easily transferable. The more parties that have access to information, the more likely it is to spread and lose value.

Really?

So Apache or Linux (bunches of informational bits and bytes) lost value as more people downloaded it? So the more people read the Illiad, the Lord of the Rings, or a poem, the less worth they have? So the more people know where to find your shop, the less worth the information of its location has? So the more people have listened to a song by a certain artist, or the more have it in mp3, the less it is worth (for instance in terms of cash that he can get out of a concert that is based on the fame that came from the song)?

Obviously there are some gaping holes in your logic. Some information might decrease in value as it spreads, but most information that falls into that category isn't really THAT worth having. Basing a model on selling that kind of information doesn't seem, to me, like such a good plan...

Daniel

[reply] [top]

[»] Re: Just one thought...
by jorgegv - Nov 23rd 2002 13:48:58


> # Information is easily transferable.
> The more parties that have access to
> information, the more likely it is to
> spread and lose value.
>
> Obviously there are some gaping holes in
> your logic. Some information might
> decrease in value as it spreads, but
> most information that falls into that
> category isn't really THAT worth having.
> Basing a model on selling that kind of
> information doesn't seem, to me, like
> such a good plan...
>
> Daniel
Obviously, it's you who didn't get it the first time. I think he means that the more people having the info, the easier it is that someone shares it, thus you loose "potential clients". That's how information gets devalued, because it can be got for free instead of from you.

Also obviously, the information which suffers from this issue is information that is SOLD from the beginning. If you are giving it away from the start (i.e. Free software), it already has NO ECONOMIC VALUE, so it won't loose any value.

[reply] [top]

---

[»] Re: Just one thought...
by shire - Nov 23rd 2002 17:38:49

This is correct, we need to clarify that there's a difference between the monetary value of a product (information) and the percieved value of notoriety. Your correct in thinking that software is more valuable when more people use it (what would it be worth with no users?). But when we look at the actual sale value of information, we can easily be undercut when there are easily accessable competitors. What I can sell information for is directly related to how accessible it is.

[reply] [top]

---

[»] Re: Just one thought...
by KDan - Nov 24th 2002 04:28:25

Maybe this points towards the idea (as expressed by that microsoft-employees-written paper That attempting to sell information is futile)...

All the credit goes to the initiators of this idea for trying to find a solution, but the 'tipping' kind of payment seems more lasting: pay for something you use/like because you want to help it become better, or you want to reward the creators, etc. Moving from a model where information gains value by spreading to one where it loses it just seems like a bad bargain...

Daniel

[reply] [top]

---

[»] Re: Just one thought...
by shire - Nov 25th 2002 23:40:00

% but the 'tipping' kind of payment seems
> more lasting:

I could see this lasting only as long as developers do this work out of the kindness of their hearts. I have happy users, but they don't pay the bills.


> creators, etc. Moving from a model where
> information gains value by spreading to
> one where it loses it just seems like a
> bad bargain...

I'm not sure I understand the perception that this model loses it's value? We should not confuse value of notariety and value of sale. Linux is nearly worthless as a sale value, but is very valuable in it's popularity. A good ransom project would steadily increase in popularity and decrease in sale value as the developer gets closer to being fully compensated for their work.

[reply] [top]

---

[»] Ransom agencies...
by tongaloa - Nov 23rd 2002 10:56:38

Musician puts a few tunes on the net and lots of people like.
He holds his next tune for 'ransom'. "$5k in my bank account number ppppqqqqrrrrzzzz and I'll turn loose of the new tune
that you'll really like".

What need for an agent?

Agent, "I can promote your music, I'll pay you up front, and I'll collect from the fans". Sounds like a record company to me.

Agent, "I'll promote your tune, and collect your money for a 'fair' fee and let you have a 'fair' amount of it". Sounds like a
'communist' record company.

Help me out here.
What role can the agency play that will benefit the user or artist?

-t

--
-everything you know is wrong-

[reply] [top]

[»] Re: Ransom agencies...
by Lion Kimbro - Nov 23rd 2002 11:19:06


> Help me out here.
> What role can the agency play that will
> benefit the user or artist?
Sure. My best friend Joel is a genius at sound and music, but has a deep aversion to business. I love to play video games with good sound music. An agent sets up Joel with a few good game companies on a contract basis, and then Joel gets paid, the agent gets paid, the game company gets their sound and music, they get my money, and I get my game.

The agent is a wire between genius talent that's business averse, and game companies that can use that talent.

If you can do the work of producing great work AND marketing yourself, then you don't need an agent. That's great! Madonna's like that, and she's done really well for herself.

But if you're Joel, then you will GREATLY appreciate your agent.

In this case- If you want to create your OWN escrow service, great! More power to you! But if you think it's a great idea, but don't have the time to work on it, you can use his.

[reply] [top]

---

[»] Re: Ransom agencies...
by J. J. Ramsey - Nov 23rd 2002 15:48:52


> What role can the agency play that will
> benefit the user or artist?
Trust, for one. If random Joe Schmoe says, I'll let you download myLatestSong.ogg if I get $XXX,XXX, then for all I know, the guy could be scamming me. If there is an intermediary whom I know is legit, either because of press releases that Joe Schmoe couldn't have distributed on his own, or because the agent also represents several other artists, then I have more reason to trust that Joe Schmoe with his agent will deliver.




[reply] [top]

---

[»] Re: Ransom agencies...
by Don Hinshaw - Nov 23rd 2002 18:43:21


>
> % What role can the agency play that
> will
> % benefit the user or artist?
>
>
> Trust, for one. If random Joe Schmoe
> says, I'll let you download
> myLatestSong.ogg if I get $XXX,XXX, then
> for all I know, the guy could be
> scamming me. If there is an intermediary
> whom I know is legit, either because of
> press releases that Joe Schmoe couldn't
> have distributed on his own, or because
> the agent also represents several other
> artists, then I have more reason to
> trust that Joe Schmoe with his agent
> will deliver.
>
>
>
Trust comes from the escrow company covering all the legal angles, and naturally the caveat that if the artist doesn't release another work, you will get your money back from the escrow company.

[reply] [top]

---

[»] Re: Ransom agencies...
by shire - Nov 23rd 2002 17:52:46

Both of the responses here are in line with my thinking. This site was never created with a master plan of agencies and clients. It was created becasue I needed credit card processing and management for my project to be ransomed. I decided to create this so everyone else could save themselves the time and trouble. I don't see this being a very lucrative setup for me in particular, at most I would take out a small fee to cover costs and dev time (which is currently not being done at all, with the exception of paypal fees). If a developer wants his/her own setup I would expect them to do so. I don't see the Technology Ransom Network being any more of an 'agent' than freshmeat.

[reply] [top]

---

[»] Re: Ransom agencies...
by Don Hinshaw - Nov 23rd 2002 20:11:34


> Both of the responses here are in line
> with my thinking. This site was never
> created with a master plan of agencies
> and clients. It was created becasue I
> needed credit card processing and
> management for my project to be
> ransomed. I decided to create this so
> everyone else could save themselves the
> time and trouble. I don't see this
> being a very lucrative setup for me in
> particular, at most I would take out a
> small fee to cover costs and dev time
> (which is currently not being done at
> all, with the exception of paypal fees).
> If a developer wants his/her own setup
> I would expect them to do so. I don't
> see the Technology Ransom Network being
> any more of an 'agent' than
> freshmeat.
>
Unfortunately, having individual developers each handling the ransoming of their particular software package(s) won't work, due almost entirely to the trust issue mentioned above. Some developers, such as Apache.org or ISC might be able to pull it off (I personally can't imagine Vixie running off to Bermuda with the cash), but even then, unless they make the effort to put some legal binding into the process, there won't be any guarantees of what happens to the money, and thus no trust.

Trust is the pivotal issue, and for lots of developers to participate, due to the fact that they cannot be trusted, some trusted 3rd party must act as escrow agent. The question then becomes, "who will act as the escrow agent?".

The most obvious entity at this point would be OSDN. It would not be a huge undertaking to add ransoming features to Sourceforge (cross-linked to Freshmeat as well), and OSDN has the resources to insure that all of the legal and accounting issues (some of which I mentioned in my previous post below) are properly dealt with.

(NOTE: I am not affiliated with OSDN in any way. Nor is this a recommendation that they handle escrow, but it works for now as a hypothetical.)

So supposing the the issues with escrow have been addressed, the next most important issue is how to decide the value of a package.

This is an extremely nebulous concept. What are some of the criteria to be used to determine value? Here are a few off the top of my head:

Number of lines of code.
Time invested by the developer(s).

There are objectice perhaps, but certainly untrustworthy.

How about the number of users of the software? Is the software more valuable if more users use it, or it is less valuable if more users use it? This is simply apples and oranges, as a higher number of people using and paying for the software increases the value, but decreases the cost. Still, this gives us no idea of the monetary value of the software.

Can we simply depend upon the developer to set the price? Probably not.

So how do we determine what the value of a particular project is?

-=dwh=-



[reply] [top]

---

[»] Re: Ransom agencies...
by dakoda - Nov 23rd 2002 20:45:24


>
> So supposing the the issues with escrow
> have been addressed, the next most
> important issue is how to decide the
> value of a package.
> ...

> Can we simply depend upon the developer
> to set the price? Probably not.
>
> So how do we determine what the value of
> a particular project is?
>
> -=dwh=-
>
I think this is perhaps the most challenging aspect of this thing overall, simply because it is relativly undefined.

I am wondering if a sort of adaptive-over-time approach is at all useful. the developer can set the price they'd like, and let that stand. As time passes without any promising developments financially [another nebulous idea], the price can be adjusted, down to a certain lower threshold. This way, the developer gets at least some compensation, but no body really feels ripped off. If they think the price is unreasonable, they can simply wait until it gets more in what they percieve to be a reasonable range.

This setup also may take into account some trust, to a degree. If I trust the developer of some project, I would feel more inclined to compensate them at a slightly higher rate, letting the rate stay somewhat high (people support this development/developer), indicating a trustworthy investment. of course, some stats would be needed for this, so someone can't just submit so much to keep it's value overinflated.

There may need to be a lock put in place to keep developers from blatently overestimating consistently, but there's not much of a reason to do so. If someone is willing to pay outrageous prices for something, so be it, it'll be free afterwards anyway.

[reply] [top]

---

[»] Interesting idea, but...
by Don Hinshaw - Nov 23rd 2002 06:31:08

Tekrat assumes the role of an escrow company, collecting, holding and disbursing funds. This raises a lot of questions. Here are a few:

Does anyone there have any experience running an escrow company?
What sort of accounting software would be used?
Is the escrow company a non-profit corporation?
Where is it incorporated?
How does Tekrat cover expenses?
What happens to any interest that accrues?
If all accounting is done in-house, then who is the independant auditing firm? (please don't say "Arthur Anderson").
If the accounting is not done in-house, then who are the accountants?
How is income tax reporting handled?
Who are the attorneys for the escrow company?
How is the ransom amount (value) of any particular project calculated?

These are just a few questions that pop into my head right away, I'm sure there are many many more that would need to be answered before a viable ransoming system could be completed.

-=dwh=-

[reply] [top]

[»] Support,freedom and Quality
by ngahleng - Nov 23rd 2002 04:59:15

In deed, that's a first time I carefully read the article at freshmeat. I wonder, am I right to put the chapter of develop cost, marketing cost in my docs. when I begin to design aphpMyLayers and try make people use of it.
Because the how to grant support,freedom,quality of software is consider in both user and developer. I agreed the view ot this subject.

--
webService at SG

[reply] [top]