Just a quick note since I did not read your email.
For me I always meant not be forced to pay, just be able to give money 
on a project I like :)

Stef

On 17 déc. 04, at 12:43, Avi Bryant wrote:

> On Thu, 16 Dec 2004 13:37:12 -0800, Michael Latta <lattam at mac.com> 
> wrote:
>> This brings up something I was thinking about recently.  Is it kosher
>> to charge for enhancements to Squeak?  Even if you adhere to the 
>> letter
>> of the license, is it socially acceptable to this community.  What if
>> the next release of MC cost $5, what if a JIT cost $25.
>
> I suspect the result of charging $5 for the next release of MC would
> be that almost everyone would simply continue to use the current
> release, or add whatever new features they wanted themselves.  This
> isn't even because people care about the $5, but because it's less
> hassle and more peace of mind to use something that's free (especially
> if there was any attempt to circumvent pirating; nobody wants to enter
> a serial number every time they load MC into an image).  I could be
> wrong, but my guess is that for a tool to gain widespread adoption in
> the Squeak community, the code itself needs to be available freely;
> anything else will get routed around.
>
> Something like a JIT is a slightly different story, because it doesn't
> really need widespread adoption to be effective.  There's no network
> effect with JITs; the fact that nobody else in Squeak is using it
> doesn't make it significantly less useful to someone who is.  So in
> theory you could license a JIT for a large amount of money to a very
> small number of customers who really cared about their Squeak
> application going faster.  This is how Zend made money (or tried to)
> from PHP.  The problem is that in Squeak's case, this number may be <
> 1.
>
> And, come to think of it, there is a potentially interesting network
> effect from having a free JIT for Squeak, which is that you may
> attract more people to Squeak itself - if you could say "Squeak is as
> fast as Java" and mean it, Squeak might grab some market share it
> wouldn't have otherwise, which would, among other things, increase the
> profile/reputation/employability of the JIT implementor.  This might
> be worth more in the long run than the (<1 ?) licenses you would have
> sold.
>
> So I'm somewhat skeptical about selling licenses for Squeak tools
> (this is very different, of course, from selling licenses to endusers
> for things built on top of Squeak, which is very worthwhile).  But it
> does seem like there should be some way of getting funding to the
> people that are doing interesting work in the community.  A few
> options:
>
> - bounties.  This has already been mentioned.  For example, people
> might pledge to pay $500 for a VM that increased the send speed by 5x
> or more.  If enough people made that pledge, a JIT implementor might
> become more motivated.  This probably works best for things like
> performance that can be (somewhat) objectively measured; I'm not sure
> what kind of a bounty someone might offer on version control features,
> though I'd be happy to find out :).
> - prioritized support.  As you'd expect, people that retain me for
> consulting, or negotiate a support contract with me, get their emails
> and bug reports (say, for MC) addressed somewhat quicker and more
> fully than anyone else.  It might be possible to formalize this
> somewhat and have, for example, a "registered user" mailing list with
> a yearly subscription fee, where messages were guaranteed to be
> treated as high priority by the tool implementors.
> - donations.  Either to individual projects (a paypal link on each
> SqueakMap entry?), or to a central foundation; with this last,
> probably the most effective thing would be for the foundation to then
> fund individual Squeakers for a few months or a year at a time,
> letting them focus full time on contributing to Squeak.  This is,
> IIRC, how development on the Perl 6 compiler happened for example.
>
> Some of these things have been tried before - there's a page somewhere
> on the swiki with a list of bounties, for example.  But since nobody
> has really come up with a successful model yet, it's worth continuing
> to talk about.
>
> Avi
>