Funding software development?

On Tue, 4 Jun 2002, Francois Gouget wrote:

> But I assume you were just digressing. Anmyway, your reasoning is
> incomplete: you cannot conclude that Stallman made more than $35000/year
> just because he asked $350/hour. You have to also show that he was
> employed at that rate for a substantial percentage of that year.

Yes, of course I was digressing.  I tend to do that. ;-)

It doesn't matter what his annual income was.  If he could earn that 
$35,000/year with 2-3 hours per week of work, that means he'd have tons of 
time leftover to write free software in his own time, and still be able to 
have a life.  If a programmer is working full-time for that 35,000/year, 
he'll either have little time left for volunteer programming, or have to 
give up on having a life to devote significant time to free software.

And even if that full-time job places all his work under the GPL, that 
doesn't allow the programmer to work on things that interest him.  He has 
to work on what his boss tells him to.  Lots of cool stuff that might be 
written if the programmer has his way may never see the light of day if 
nobody wants to pay him to write it -- unless he sacrifices himself for it.

> > Seems like he's not practicing what he preaches, yet he remains
> > completely unconcerned about the potential for the GPL to decimate the
> > programming profession and turn is all into wage slaves.  Programmers
> > might even be forced to search for jobs unrelated to computers, if
> > there's not enough programming work available.
> 
> You may want to read the following:
> 
> http://www.opensource.org/advocacy/jobs.html

If you really want me to address my doubts on a point-for-point basis,
I can, but I'd rather not take the time.  Let me try to keep this short 
(for once) and say that I'm familiar with the party line, and I'd like to 
believe it.  However, the case it makes isn't compelling, even if it sounds 
good.  Right now the GPL is the underdog -- if it becomes the vast majority 
of all software, that could change all the rules.  The arguments they make 
might no longer apply.  It might all be wishful thinking.

I'm not saying that the programming industry WILL be decimated if the GPL 
takes over the world, but that it COULD be.  I don't know the odds, but I'm 
concerned about even the possibility.  On the other hand, I don't see it 
happening overnight.  Maybe someone can come up with a compelling solution.

> You seem to have researched Stallman's views and life quite a bit. I
> just hope you are also researching Wine as thoroughly so that you can
> soon emit informed opinions.

I've been a supporter of free software since the late '80s.  Only in the 
last couple years have I started to become concerned about the possible 
dangers of Stallman's vision.  This is partly because the business models 
advanced for open source haven't really worked as well in practice as they 
do in theory.  "Free beer" is very compelling, and a prime driving force 
behind the GPL's success.

Stallman can emphasize "free speech" all he likes, but it's the "free beer" 
aspect that keeps people coming back for more.  That's also the aspect that 
could endanger the computer industry if the GPL ever manages to eradicate 
most proprietary software.  And make no mistake about it, eradicating all 
proprietary software is definitely Stallman's goal; he doesn't hide that.

> Here are a few starting points:

Hey, thanks for the pointers!  It certainly helps to know what some of the 
key points of discussion have been...

>  * Gavriel State - TransGaming DirectX Release
>    (You said you did not know which promise they made, now you know)
>    http://www.winehq.com/hypermail/wine-devel/2000/12/0358.html

Okay, I see that they promised:

* Release of Direct3D code under the AFPL -- was this done?

* Release of DirectDraw code under the Wine (X11) license -- was this done?

* Release of all Wine code after a "set number of users" have subscribed to 
  their service.

If they didn't do either of the first two releases as described, then they 
have clearly broken their promise.  If they followed through on just the 
first two, but not the last part, from the above message alone, I can't say 
that they've broken a promise.  That's because they've got a loophole in 
the "set number" -- they didn't specify the number.  (Did they specify a 
particular number later?)

It's possible that they intend to follow through on the third part of this 
promise, and they never reached their initial goal for subscriptions.  This 
would be legitimate, but they ought to make it possible for the community 
to verify this.

If they want any trust from the community on follow-through, here what they 
should have done:

* Make a public commitment as to the EXACT minimum number of subscriptions 
  are necessary (1) for the initial release and (2) for ongoing release of 
  later patches.

* Keep open books on the number of subscriptions, so anyone can check at 
  any time how near or far from the mark the number is.  (Possibly list the 
  individual subscribers for verification, but this might have implications 
  for subscriber privacy.)

* Follow through with the code release when the threshold is met.

Now, I don't know if they did any of these things.  Certainly, they could 
hide the information about their subscription goal and their actual number 
of subscriptions, but this leaves them open to suspicion that they aren't 
going to play fair -- if the numbers are hidden, they could easily raise 
the thresholds without anyone being able to prove that they did so.  They 
could also lie about whether the threshold had been met.

I don't have enough information yet to know if they've broken this promise.

>  * Ove Kaaven - Re: CoGetClassObject
>    (how the InstallShield stuff started)
>    http://www.winehq.com/hypermail/wine-devel/2001/08/0035.html

Okay, I don't know how this fits in here just yet.

>  * Me - Problem with InstallShield...
>    (completes and puts the above two together)
>    http://www.winehq.com/hypermail/wine-license/2002/05/0056.html

Here you seem to say that they did release DirectDraw code, but not any 
Direct3D code.  Assuming you're talking about under the Wine license, this 
doesn't necessarily indicate a broken promise (unless they failed to make 
the AFPL release promised).  The question about what other developers 
should do about Direct3D is valid, but ultimately it's up to them -- they 
can go ahead with work which may be duplicative, or continue waiting.  It's 
no different from a small company having to decide whether or not to work 
on a product when faced with a possible vaporware announcement from some 
competitor.  Yes, it's a difficult question.  That's life.

As for the InstallShield issues, I don't see any indication that TG ever 
indicated that they would release any work in this area just because they 
were aided by others in the Wine project.  Maybe people jumped to that 
conclusion, but their original promise actually implied that most of their 
future code would also remain closed unless and until their subscription 
goals were met.

I agree, maybe Huw should have traded the STLG patches for InstallShield 
DCOM code.  Perhaps he made a mistake in trusting Transgaming to release 
their code just because he helped them along.  I imagine people will be 
more cautious with them in the future.

>  * Alexandre Julliard - Re: Problem with InstallShield
>    http://www.winehq.com/hypermail/wine-devel/2002/05/0232.html

This is an interesting post.  From this, it would appear that Alexandre 
really cares relatively little about the final result (the best possible 
Windows emulator), but rather on the process -- the journey to GET to that 
intended result.  Anything that makes the journey less enjoyable, he wants 
to avoid, whether or not it helps with the final result.

Now, there's nothing wrong with this, if the value in the project comes 
from the journey, not the result.  Certainly, the value of a party is the 
experience, not the "contributions" made in music or food.  However, nobody 
doubts that the GOAL of a party is also that same experience.

Maybe the real conflict here is between those who value the journey more 
(e.g. Alexandre and *GPL supporters?) as opposed to those who value the 
results more (e.g. Transgaming).

This also has bearing on what's "best" for the Wine project.  Personally, 
I'd like to see the best results.  The journey is secondary in my mind, 
which is why trading patches seems logical to me.  However, I'm not really 
participating in that journey, so the amount of value it offers is really 
irrelevant to me at this time.

It seems that Alexandre's viewpoint is that what's "best" for the project 
is whatever enhances the journey and makes the experience of implementing 
this project more enjoyable.  From this viewpoint, trading patches does not 
make sense, because it does nothing to enhance the journey.  Sure, it may 
bring you closer to the end goal, except that the REAL goal is to enjoy the 
journey, not to finish it.  Finishing the journey would end the experience, 
so in a sense, finishing it sooner detracts from the journey.

This is speculation on my part, but it seems to fit with what Alexandre has 
been saying.  And if this is truly the perspective her's coming from, then 
there's probably no way to convince him -- because trading patches wouldn't 
enhance the journey, and could even cut it short.  I can understand why he 
would oppose that, if it's the journey he values above all else.

I'm not going to suggest that this viewpoint is wrong.  On the contrary, my 
interest in attempting to write an OS myself (if I ever get a Round Tuit) 
is entirely in the journey.  I think writing an OS would be a very valuable 
experience, so I'd like to do it.  The end result is secondary; I'm sure it 
would be hard to get anyone to use it, if I even write it and make it work 
well enough to be useful.  If the end result is valuable for itself, then 
great.  If it's worthless garbage, that's okay too; it's about the journey.

Regarding Wine, in particular, the thing to keep in mind that there are a 
LOT more people out there (millions, in fact) that are only interested in 
the end result (emulating Windows), who don't care about the journey.  Now, 
the actual developers doing the work can value the journey over the results 
(and no reason they shouldn't, especially if they're volunteers), but you 
can expect a fairly constant pressure to come from people looking for the 
results, and nothing but results.

Perhaps the "right" answer is that Wine and Rewind go their separate ways, 
and Wine can focus on the journey while Rewind focuses on the results -- 
that way both viewpoints can be represented.  Maybe the LGPL fork, with its 
focus on collaboration, will achieve the best result first anyhow.  Maybe 
the Rewind fork will, if sufficiently supported by commercial interests.

Who knows?  May the best fork win, I guess.  I say, good luck to all, and 
enjoy the journey!  (If that's important to you...)  :-)

>  * Me - Re: Wine license change
>    (trying to describe why I think the LGPL is good for Wine)
>    http://www.winehq.com/hypermail/wine-devel/2002/02/0289.html

I think there's pros and cons to both licenses.  The BSD/X11 licenses are 
certainly more open to abuse, though many companies have often found it 
beneficial to contribute back anyhow.  But just as certainly, others won't.
Microsoft has adopted BSD code and I've never heard of them giving anything 
back in return, for example.

On the other hand, from what I've read so far, it seems like Transgaming 
was actually trying a novel new business model -- convincing end-users to 
subscribe to a "service" to support development, and releasing that code 
back to the public project once it's been paid for.  There may be doubt as 
to whether or not they followed through, or they may have had a much harder 
time finding subscribers, but it's an interesting approach.  It's at least 
one possible solution to the problem of funding free software development.

Now, this sort of negotiation impedes the journey of writing the code and 
turns it into more of a mercenary business transaction, so I can see why 
Alexandre and others might find the business model distasteful.  Yet, from 
the standpoint of one who's more interested in results, it's not a bad idea 
for achieving results more quickly.  After all, if you can fund development 
work, the developers don't need to work a "day job" for a living -- they 
can focus all their time and effort on improving the code.  This is a good 
thing for the millions of people who'd like to benefit from their results.

Now, if Transgaming fails to follow through, assuming they get "enough"
subscribers (whatever that may be), that would be very disappointing, but 
it doesn't mean that their proposed business model is necessarily flawed.  
The only real flaw I see in it (from what I've read so far) is the danger 
that too few people would be willing to subscribe, because everyone can get 
the benefits by letting someone ELSE subscribe and take the burden.  Maybe 
the fatal flaw in their business model (if there is one) is that nobody is 
required to pay their subscriptions, so maybe nobody (or too few) will...

From a standpoint of looking for results, I don't see anything wrong with 
Transgaming's business model, though it's not guaranteed to work.  It's a 
creative way to fund development that otherwise WOULD NOT HAPPEN.  What's 
so bad about that?  It's worth a try.

From the standpoint of valuing the journey above all else, Transgaming's 
mercenary model may be somewhat at odds with it.  But that's likely to be 
the case to some degree or another with ALL commercial interests, since 
they're (almost by definition) going to be interested in results, not the 
journey.  Maybe the LGPL is enough of a middle ground where some of the 
commercial interests can join the party without detracting from it, and 
also benefit from the results.  Others (like Transgaming) would have to 
discard their business model to do it.

Suppose Transgaming were to discard their business model and switch to the 
LGPL codebase, as Alexandre has urged them to do?  How would they be able 
to pay their developers and stay in business?  Lindows is looking to sell 
boxed software, and that may be successful; Red Hat has proven that it's 
possible to make money from boxed software even if the underlying code is 
freely available.  People will pay for the warm fuzzies.

Should Transgaming try to sell boxed distributions?  That's an expensive 
proposition, and it just guarantees more fragmentation in the marketplace.  
There's a market for people who want to buy their softwre in a box instead 
of downloading it.  To provide that requires a manufacturing infrastructure 
and additional talent for artwork, documentation, etc.  Those user who are 
willing to download instead of buying boxed software will probably just get 
the free version, especially if downloading it from Transgaming wouldn't 
give them any tangible benefit.  Besides, the boxed software may well be 
able to support Lindows OR Transgaming, but not necessarily both...

There's a real market for boxed software, free or not.  People will buy it 
because they value having this tangible THING for their money.  They're 
getting something extra for their money; it's not just a donation.  Paying 
to download from someone when the same download is available free elsewhere 
is tantamount to a donation, and it has been shown again and again that 
free software doesn't tend to bring in THAT much in donations, because most 
people won't benefit and will stick with the "free beer", no matter how 
much value they may get from the software.

I'm all for creative funding of free software, but I'm starting to think 
that nothing is going to be truly effective until the "free beer" is taken 
away and people pay for the software, getting "free speech" rights.  Until 
the two concepts are separated, I don't see any means to fund any massive 
development work on anything.  People SAY they value "free speech", but 
their actions speak louder than their words, and actions say most people 
value "free beer" more in the end.

It's like that classic sign: "Everyone who comes in here wants three 
things.  They want it done cheap.  They want it done fast.  They want it 
done well.  I tell them to pick any two and get back to me."  Free software 
depands "cheap" (free).  Half our decision has already been made for us.  
We end up with free software done fast (but not well), or done well (but 
not fast).  Hoping to get all three may be a pipe dream.

There's plenty of examples -- lots of little free software projects are 
garbage, because someone just slapped osmething together and released it.   
Maybe it was fast, but not done well.  Many others are excellent and high 
quality.  They've also taken years to get to where they are.  You don't 
find large quantities of high-quality software coming out rapidly because 
that's EXPENSIVE.  You have to pay a lot of developers a lot of money to 
have a chance of making that happen.  And with the "free beer" aspect of 
free software, it's hard to recoup that expense later.

I envision a community which has dues for its members (it's not free) and 
perhaps subscriptions to certain pieces of software.  Subscription revenue 
could be used to fund development of the software being subscribed to (and 
the license does NOT allow non-subscribers to use it), while general dues 
could fund software development in general (new or existing projects).
There could be multiple "levels" of membership, where the higher levels 
cost more, but offer rights to more software.

Now, within this community, you could have "free speech" rights -- you'd 
get all the source code, and have the right to modify it, and give your 
changes to others, but they'd need rights to the base code to use your 
modifications.  (I'm not sure if people should be allowed to distribute 
modified copies, or only patches.)  Outside this community, there's be no 
"free beer" -- if you wanna join the party, you gotta pay the cover charge 
at the door.  Once you're inside, party away.

I think something like this could work, and more importantly, provide a 
revenue stream that could fund development for the benefit of the entire 
community.  Of course, getting it started is easier said than done -- until 
you have something to offer, why would anyone join?

I've been thinking about trying to create such a community, but I think it 
wouldn't have any credibility unless it's administered by a non-profit 
organization.  As I understand it, that's somewhat of a hassle to create 
and run, but without that restriction, many will assume you're profiteering 
instead of trying to help the community.

I know I've digressed well off-topic here, but does anyone have any ideas 
about whether or not this could work, or how it could be improved?  Just 
bear in mind that the key goal would be to provide a revenue stream for new 
development work, which means eliminating "free beer" from the equation -- 
all OSI-approved licenses would necessarily be out.  Now, it could still be 
"cheap beer", it just can't be "free beer"...

Thoughts, anyone?  I'm seriously considering trying to implement this...

Deven