Re: Object usage payments

["Alexey Parshin" <alexeyp@gmail.com>]

So, how are you going to stimulate authors to develop UMOs? Especially, on commercial server? What's the point to write the text, or develop are complicated multi-level UMO, if you aren't get paid? Donations may work for certain category of people/UMO and for certain conditions. But if you want to have commercial server - it doesn't work, IMHO. 

Also, UMO price offers ways to regulate any funds paid for the class. W/o a UMO price, we can't distinguish the amount of work put by different authors.. 

We can, of course, define a new entity, 'Agreement', and define the percentage of every author for the course.

2007/6/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

Alexey Parshin wrote:
> Ok, the question is, then:
>
> If any UMO is included into any other freely, how do the authors of
> the UMO get paid?
They don't.
> In my understanding, every UMO has a price of usage (one way or
> another, including price = 0).
This is where you are off. UMOs don't have price. We can associate
donations with them.
Maybe. But that's it.

> In turn, if a particular UMO of one author includes some UMO(s) of
> other authors - the payment for that UMO should get to other authors
> somehow..
>
> 2007/6/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     Alexey Parshin wrote:
>     > Gentlemen,
>     >
>     > It's time to discuss - how do authors may define the payment policy
>     > for their UMOs. I came up with the following potential policies:
>     >
>     > 1) Fixed payment. Once an author pays a UMO, he can use it in as
>     many
>     > other UMOs as he needs. I doubt that is what the author of this UMO
>     > wants.
>     > 2) Fixed payment for any including of the UMO in one's UMO.
>     > 3) Periodic payment: same as 1) but with lease period.
>     > 4) Periodic payment: same as 2) but with lease period.
>     > 5) ?
>     From the original proposal:
>     ---------------------------------------------
>
>     10. Following class creation rules are available:
>         - Fully open, accept donations: anyone can create class, if
>     donation
>     of minimum
>             is given to author, teacher has an option to show a stamp
>     on his
>     course. Not
>             giving a donation will show up on course as well.
>         - Fully open, don't care about money: anyone can create class, no
>     donation absence
>              marker will be shown.
>         - Payment required, perpetual: Fixed payment is made, and class
>     exists indefinitely
>         - Payment required, periodic: Flat rate payments for defined
>     period
>     of time.
>         - Payment required, percentage: Percentage of teacher's income
>     from
>     this class
>
>     ---------------------------------------------
>
>
>     >
>     > These policies, of course, should be implemented as stored
>     procs, so
>     > we can always define more. But I need to estimate at least the
>     general
>     > requirements for them.
>     One important thing is: we do not bind payment to an UMO. Any UMO
>     can be
>     included
>     into another one without limitations (except for limitations
>     imposed by
>     kinds - can't make
>     a topic a part of a problem). With this in mind, you'll realize it
>     makes
>     no sense to assign
>     payment to any UMOs besides course (which is the only
>     non-shareable UMO
>     - you can't
>     include the course itself into anything else).
>     >
>     > It is more or less clear, that every non-free UMO should have an
>     > account. Such accounts would be created simultaneously with the
>     > payment policies. The absence of the payment policy indicates free
>     > object.
>     >
>     > A separate issue is a distribution schema. A payment(s) made to
>     a UMO
>     > account,  eventually (or periodically) should lead to author's
>     payments.
>     > After some money paid to UMO's account, how do we distribute this
>     > money among the authors? We can, of course, just distribute the
>     money
>     > among the author(s) of top-level object. But, is it the only schema?
>     The issue is not distributing money between authors of UMOs (for
>     reasons
>     stated above), but between authors of a course.
>     We need to come up with a way to let authors come up with proper
>     distribution of funds between each other.
>
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net

--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com

-- 
Alexey Parshin,
http://www.sptk.net