more lockup laptop problems with dapper

[Eric S. Johansson]

Brian McKee wrote:
>> trying for a snark free zone ;-)
> 
> Somewhere to the left of Valhalla - watch that first step! :-)

and probably about 15 minutes after Ragnarök too.

> I've no direct experience, but that certainly sounds right.
> The quality of the participants is (always?) the biggest factor.
> 
> What do you think of the argument that says 'a labour of love done beacuse
> the developer wants to do it' will produce better quality code?  By removing
> all that pressure, and making it easy for him to either sleep on a problem or
> kick it around with any and everyone, doesn't that aleviate all those issues
> you discuss?

to tell you the truth, if you don't love the code you are writing, 
you'll write mundane boring crap code.  I swear to God I love OS 
internals.  I absolutely love doing things with e-mail that makes most 
users smile and most geeks grind their teeth[1]   on different projects 
when the various developers (myself included) loved writing code and 
were committed to the product, we produced really good code that just 
ran.  In contrast, I've been on other jobs where we put in time because 
we were flogged and of course, the code was relatively crappy (and still 
my code was rated highest quality by peer review.)

extending this experience towards the open source world, yes I think the 
highest quality code does come from people who love what they are 
working on.  I will admit my code quality has slipped over the past few 
years because it is difficult to write code with speech recognition.  I 
really need someone to work with me to help me fix up various problems.

But it's really important to understand how the code is subsidized.  For 
me, it's a subsidy that comes from my consulting revenue.  If I don't 
make billable hours, I can't subsidize my own writing time.  If I was an 
employee, I would be minimizing my time at work and maximizing my time 
on open-source.  Why?  Well, it would probably be more interesting than 
what my work project was.  :-) I suspect this latter condition is the 
mechanism for funding much open-source software development.

> Well, 'hiring' a programmer to produce code is certainly an option.
> How do you 'make sure it's done right' though?   I guess that problem
> exists regardless...

but it's beyond my financial wherewithal to hire a programmer even for 
small project.  It's way beyond most people's resources to hire a 
programmer especially if they work in a 9-to-5 job.  Unless of course 
it's exploiting the difference between first world and Third World 
environment.  But even then, think most people would be stretched

ass for "done right", there are a series of really good techniques for 
defining "Done".  I personally use completion criteria at a gross level, 
and it's hard to write good completion criteria that mean anything.  At 
a lower level, you can use "programming by contract"[2]

>> I personally believe we have been training our users too much to expect
>> free (i.e. no cost) and not enough on how much it costs to remain free
>> (i.e. liberty).  No matter what version of liberty you talk about, it's
>> never cheap.
> 
> Is that our training?  or just a reflection of current society?
> I do agree that there should be more emphasis on 'what actions you can do
> that will help pay back' but hey - free means 'free to take what you want
> and ignore the rest of that philosophy stuff' too right?

that's a good question.  We have a lot of commercial advertising "free" 
when in reality it's subsidized of a monthly fee (i.e. cell phones). 
Other products are subsidized through cost shifting.  Is the free 
Coca-Cola you get with your pizza really free, just buried in the cost 
of the pizza, or buried in the cost of future Coca-Cola purchases.

But at the same time, when you read articles about Linux, you typically 
see people talking about free distributions and free software referring 
to free of cost.  So I think the answer may actually be that users are 
primed by cultural message to look for something "free" and to pay for 
"free" things by subsidy or cost shifting.  So they come to Linux, get 
something for free and then there is no mechanism to deliver money to 
the people doing the work via subsidies or cost shifting.  Whoops.

In order to close the final step, we need some mechanism for people to 
deliver money and folks to apply for and get money.  For example, the 
trust ubuntu has earned may in turn also be applied to a payment system. 
  I.e. we trust ubuntu to deliver good releases therefore we will trust 
them to deliver money to developers.  We would need some way to detect 
which packages are used or failing that, loaded onto the system.  Based 
on utilization, money could be delivered to the package developers.

Rough idea but it's like metering for software but not to punish the 
user.  It's only there to reward the developer if they want to participate.

> I'm hoping the soft sell approach will make sure the largest number
> of people possible will see it, and hook the people willing to think
> about such things sooner or later.

it's really funny what catches the idea of various developers and what 
doesn't.  Like I said before, I have seen some extremely good projects 
fall by the wayside and for reasons I can't understand.  The only thing 
I can see is that developers aren't good at PR and you must be good at 
PR in order to have an open-source project become popular enough to let 
you make money off it.

> Bah - my reply was arguably worse than yours - no biggie, and
> my apologies in return.   I'm the youngest in a large family - a little
> friendly abuse makes me feel at home :-)

firstborn child and firstborn grandchild on my father's side of the 
family.  Can you imagine the aggregate level jealousy aimed upward by my 
cousins and sideways from my odds and uncles when they thought I was 
going take over/inherit the family machinery moving business.  No 
friendly abuse there ;-)

--- eric

[1]think about a mailing list without a central node for mailing list 
management.  It's modeled on a  non-flooding USENET propagation model. 
unfortunately, no money, no time meaning the idea is sitting on the shelf

[2]http://www.cs.usfca.edu/~parrt/course/601/lectures/programming.by.contract.html