Damn. I wish I recalled that or could find a jpg on-line. I'm really not into promoting conventional conceptions of sexiness -- but Louise was hot! I think it was the way she exuded a warrior's competence (plus, of course, the skimpy custumes).
Ok -- having found a "fan site" and his official site, it seems Tom Baker is very much alive, and very much grey. So, instead of the origins of Dr. Who, how about a combination of his origins and (gasp!) his fate. Screw perfect continuity with the TV series which is incoherent anyway.
Ya know what I wanna see? A really high budget Dr Who film about his origins, staring Tom Baker who's acting and portrayal-of-this-character-in-particular ability was barely exposed during his stint on the series, yet pretty much defined it for many americans. Man he managed to make gold out of average scripts ("I gave him a blank look"). I'll bet it'd make plenty o' money. Something about the politics of the timelords and the doctor's renegade nature.
Dr Who is a great low-budget tv vehicle -- you can do nearly any cheezy sci-fi plot within its framwork. Nevertheless, there's some neat ideas there, Baker's era stands out among all the others, and I'd like to see more. (Gosh, is baker still around? I'll bet he's all grey now.) (And, ya gotta love all those $3 BBC special effects -- really.)
Make it dark, dark, dark and funny. And make cheezy special effects part of the theme.
And bring in Leela. She was hot and smart (Janus thorn, anyone?). and sarah jane, cause she's cool too and so much a part of the tradition.
So, you put together N processors worth M mflops each and focus only on suitably parallizable computations so then you can claim M*N performance. Yeah? Really? So what?
The Arthur C. Clarke quote someone else posted (paraphrased "how many supernovas are industrial accidents") rings true with me.
If you're going to insist on creating exotic matter using very high energy processes in the absense of any accepted theory of what's going to happen, please do it in someone else's galaxy.
It's a shame the post with the correct one word answer got categorized as "funny".
Emacs is the right programming architecture for GUIs. The Emacs command set and visual appearence are, obviously, not that great for many users -- but the programming architecture is right.
By being interactively extensible, emacs makes it easy to fine tune an interface while you play with it.
By being lisp based and by having many fine abstractions, emacs let's you do a lot with very little code.
The emacs architecture provides some very fine bits and pieces for achieving excellent accessability features.
By being interactive and self-documenting, Emacs is good at helping people teach themselves to program.
View-tree toolkits, such as underlie Gnome and KDE are inflexible dogs that leaded to bloated yet feature-anemic tools. You know what they're good for? They're good if you have a command-and-control army of drone programmers who can write reams and reams of code. That's why Microsoft apps will remain far more featureful than their free competition until that competition switches to an architecture that works for a society of free individuals.
Yes, it's true: the way you structure your programs has political implications. It defines jobs. It defines the power of managers and project managers. It establishes the degrees of freedom your users have to extend or customize their tools.
Hmm. "attention to detail" was a phrase they used a lot. Ok, sure, these systems need polish.
But -- fuzzy icons -- unified shortcuts -- moving text around by a few pixels. Not _bad_ things to do, by any means. Still.
What about -- "attention to architecture", so that all of these "details" don't turn into infinitely long task lists, so that apps are far better and more consistent at being self-documenting, so that it doesn't take a ton of new code for every little app, so that interactive extensibility is built-in to the core, so that process are managed less horribly....
It's extraordinarilly configurable and I think you can get it to a state close to what you'd expect of a spherical keyboard.
I have mine with left and right halves widely separated, tented at very steep angles (about 80-degrees), with a kensington track ball sitting in the middle. The keyboard firmware isn't perfect, but works well enough. The trackball stands up to all manner of neglect and abuse.
I've also found it handy to mount a couple of button boxes around the keyboard (I have around 200 keys in easy reach -- roughly half bound to my favorite emacs commands) but my button box manufacturer has been a twit and their firmware is annoyingly flakey, so I don't have a specific recommendation here.
> and for someone as utterly friggin' brilliant as > Tom Lord to be utterly penniless [...] is just > wrong
Of course, I strongly agree.
> (as in, unable to buy beer, much less pay rent)
I am as happy as one can be under these circumstances to report that, much to my surprise, I was able to buy both this month's rent and this week's beer on the last dribs and drabs of a friend's credit. But, yeah, it's pretty bleak.
But, hey... I've got this kick-ass business and technology plan here for companies like Red Hat and all the unix vendors.... free software is _good_ for business, and I'm doing my damndest to make things work. (Hey, Scott McNealy, let's do lunch (you're buying):-)
It was certainly designed for another era and, judging by second hand reports (e.g., it uses SCCS as a back end), is not the best foundation for today's economies.
arch is far, far better in that regard. Larry has stated a few times that it would take O($12M) for arch to catch-up with bk. I think that's roughly an order of magnitude too large and that the result would be an arch that surpasses bk.
The BSDs have been "way ahead of everyone else" in engineering infrastructure for ten years -- but they aren't "there".
More specifically, the BSD makefiles and the process disciplines observed by the relatively small groups of core maintainers are nice. However, these nice properties of BSD development don't translate easily to other projects; aren't anarchic enough for the role of free software in today's markets; aren't automated enough, etc.
But -- yeah -- the BSDs are pretty inspiring.
Hmm. I have a little paper about where I think the free software business world needs to go to get "there", if anyone is interested. Write to lord@emf.net to ask for a copy.
> he was under the perception that the so-called > "community" would donate enough money to allow > him to accomplish that.
No, I wasn't. The community did keep me afloat for longer than I otherwise would have been, while I worked on getting corporate funding for a small team to finish and polish the hell out of arch.
Now an interesting question becomes: what does the bitkeeper license imply to IBM, HP/Compaq, Red Hat, Suse, Mandrake, and other businesses that depend on the linux kernel?
This event points to a more general problem: the free software business world needs a better infrastructure for all projects, not just the kernel. Now they have one more reason to believe in the urgency of this need.
No -- the right question is: who possesses the
circuit breaker. And the answer is obvious,
once you consider: who would think it to be
a critical tactical and strategic bit of leverage
to possess. Hmm. The feds. China. North
Korea. India. England. LOTS of people. An
embarassment of riches in the buttfuck dimension.
Managment (including execs and principle owners) who don't know and aren't willing to learn
about the consequences of their behavior are a scourge upon the face of the earth. Terrorists, basically.
How many people contribute Open Source
or Free Software to the world? How many
opportunities have been created by the existence
of successful, minimally reviewed GNU/Linux
distributions for professional cracker community
members to quietly introduce bugs? How many sites now run Red Hat, for example? How many of those
installations are mission or security critical?
The security problems pointed at (ever so esoterically) in the cited articles are vast,
serious, real, and pressing. They are made
worse by vendors who persue dubious features
and broken, overly complex architectures rather than remembering to KISS and empower
customers to differentiate their installations
and (especially in a disaster) manage their own
source.
The good news: using plenty of available technologies and techniques to reduce the RISKS here can, as a side effect, radically improve the overall quality of the Free/Open Source software being vended these days. We need fewer, but much better features, managed by much better software engineering practices.
That (in my opinion), rather than panicing over security issues, is where our various corporate friends ought to focus in response to this and similar articles.
All the good puzzles are well known. All that
you're testing is whether or not someone has
read the same puzzle books. If you are trying
to make up puzzles of your own, you are probably
doing a bad job.
I've never met a competent interviewer. I've met plenty who are just clueless, and some who are
asking "will you help us snow the mgt?"
Here's an update about arch and the regexps.com fundraising effort.
A few days ago, I released a GPL'ed package (the monkey directory editor for Emacs) as a fundraiser: rather than post the source or put up a tar bundle or repository, I've been charging people money to send them the source.
To my surprise, that actually worked a little bit. Some people bought copies. Great!
Today I'm trying a new variation: I've mailed out (to the gnu-emacs-sources mailing list) the source for the previous version of monkey, and now I'm offering to sell (still GPL) distributions that have some new features. We'll see.
If all of this works out, one idea I'm considering is to make all of my source available in the usual way (tar bundles, revision control repositories), but to rate-limit traffic from ".com" domains and sell FTP accounts. I think this model can be adopted by many projects, if it works, and that it won't cause any serious problems for hackers sharing code with one another (they just might want to use a non-".com" address for anonymous transfers).
This "service differential for source code" model isn't perfect by some standards. It doesn't force users to pay and it doesn't
force customers to spend their money wisely. On the other hand, this model reminds users to pay and implements a well-defined service that they can pay for.
If you like the idea of this model -- that's
another reason to support the current fundraiser!
Perhaps we can bootstrap a whole new kind of Free Software Business Model.
Yes, other projects need support as well. I regard myself as attempting to:
solve the immediate problem faced by regexps.com.
experiment with some simple business models to
find one that is compatible with hacking
build engineering infrastructure tools,
like arch, that can help to partially automate
such business models
Is there a way to make money directly for creating new Free Software? In a few cases, those of us lucky enough to get money from users, sure. In the majority of cases, in the future, I think the big companies that use open source ought to come up with funding mechanisms (and fund them!),
because that's a good way for them to spend their R&D budget.
Tom Lord is author of the only GNU
release that has ever been pubically withdrawn
(sed 3.0). Doesn't inspire much trust.
:-)
We were all young once....(some still are, I
guess). I don't particularly recall why that happened, but I'd guess it was because though the (then new) regexp engine tested well on the tests available then, it was too slow on some other cases discovered after release, by users. It only took about another 10 years to get the regexp matcher right:-) You can find the current version in the Hackerlab C library, at
www.regexps.com
I am grateful to supporters for the purchases
and contributions received so far.
I'm still a rather far from having enough
to stay on-line, but the contributions so far
suggest that there is a chance.
The problems faced by arch aren't
unique. Whenever I've talked to those more
senior engineers who are my friends and who have
lots of "open source" involvement, they say
"We're hearing this same sad story from a large
number of very talented hackers.".
The botttom line: please do contribute to arch.
It really is a fiscal emergency and your support is much appreciated. But in addition to sending support, please also send a short, polite note to
your favorite budgeted manager or exec at an
open source or free software friendly company. Point out to them that you are doing their job and spending money in a way that will benefit them. Ask them to be more proactive in supporting free software researchers, including working on their host organizations to establish some winning policies in this regard.
Um, hey -- I think I'm now obligated to
all your reading skills into question;-)
It's a FAQ, not a paper. In other
words, its designed to help orient readers
to the design space and give them a staring
point for research and comparison. I assume
that the FAQ's readers are smart enough not to
try to use the FAQ as a CS textbook.
Second, what I've tried to say in the FAQ is not that databases are overapplied (that's for another discussion) but rather that arch's
standard-file-formats and ordinary filesystem tree orientation resulted in a very tiny, simple implementation that nevertheless has many of the desirable semantic and performance characteristics people often presume require a database.
That second point isn't some loopy
overgeneralization about databases: it's an
observation about how the implementation
"came together" around simple file formats.
But yeah, thanks for the reminder that when we
really do get around to having the "proper role
of BTREEs" debate, that, in light of all the
accumulated wisdom on the topic, I'd better
speak very carefully.
There's nothing wrong with getting a bug
report that includes some money -- that's fine.
The problem is that people can only make
enough money to fund development that way
if:
(a) their program is buggy or missing critical features
(b) their program is commercially important
to users already
(c) there's no Cygnus-type company to compete against
(d) the developer only wants a minimal
hourly rate for fixing bugs -OR-
the developer is so uniquely
qualified to fix the bugs that he
can charge a huge premium compared
to other solutions
Let's look at those from my perspective:
(a) I don't like to write the kinds of program
that are perpetually buggy and always need
fixing or extending. I don't think there
should be financial incentive for doing so.
(Looking at the documentation and development
priorities of some commercially hot projects,
I think one can see evidence of that
incentive at work, but its difficult to
try to discuss that objectively without
stepping on people's toes.)
(b) I like to use my skills and broad
exposure to design new kinds of
software solutions to problems that
most people don't fully recognize
yet. In other words, much like a lot
of programmers working for MS, I like
to make it my job to work on programs
that will start to be important a few
years down the line. It would be premature
to try to support advanced development like
that on the basis of any kind of
bug-fix or feature-development contract.
(c) Well, I'm not too worried about a Cygnus-type
company wanting to "steal" my R&D business,
but such companies still pose a problem.
Suppose I thought "Well, I'll just self fund
the intial development, then start my own
support business once the project takes off."
That would be unrealistic. The more likely
outcome is "I'll self fund initial
development, then some company like IBM or
Suse will get the support contracts."
The leadership of those companies has been
so (from my perspective) ineffective about establishing any kind of
R&D funding for open source, that I find
myself seriously questioning my loyalty to
the GPL and wondering if there isn't some
better license that would let individuals
do business with my code, but tell those corps to go
screw themselves.
(d) Ultimately, bug fixing and support for
open source is a low margin business
(meaning you may as well think of it as a
minimum wage job) because there is little
or no barrier to entry for someone that
wants to compete against you. The only
winners in this kind of business are
big companies who manage to achieve
efficiencies of scale, and perhaps one
or two vanity companies, who's prestige
supports payment well above market rates.
In summary, bug fixing and support are limited,
lousy business models that do little to help
creative free-agent developers or otherwise
advance the open source R&D. This has nothing
to do with what you termed "temperment" --
it's a serious problem and we're seeing a
dismal lack of leadership from the execs who
are in a position to do anything about it.
Since those same execs tend (just as a general,
industry-wide trend) to resource starve their
in-house projects, I don't even hold out much
hope for a sudden swell of grass-roots support
for open source R&D funding from the ranks of
technical managers.
It's an alarm I keep trying to sound: redmond
(to name just one example) hasn't stopped doing
R&D. And when those companies use the label
"R&D" -- it isn't just for tax purposes. They
really do pay quite a bit to have people
form little intellectual communities, trade
ideas, and develop new systems in an exploratory
mode. They really do (judging from their output)
seem to have the goal of obsoleting the entire
generation of technology to which pretty much
every piece of open source code belongs, and,
at least from a technical perspective, they
have more than enough brain power to succeed.
The bug with this approach is that it
assumes the person spending money will
request a specific feature or a certain
level of support.
That's crazy. Businesses are already extremely
efficient at providing new features and
support. They are experts at those kinds of
contracts and open source volunteers can't
compete against them in such a simple minded
way.
The real funding need in the open source world
is sustained, long-term funding for creative,
exploratory research and development. We don't
need customers who want to buy "features" or
"support" -- we need customers who want to
simply PAY US TO HACK on new and interesting
projects that may be too new to help many customers directly
today, but that will help the open source world
evolve tomorrow.
It's because we in the open source world don't pay people to "just explore"
that Bill Gates gets to say the GPL is
bad for the industry and unamerican and that fascistic copyright protections
are a necessity.
I think there are at least two good ways
to spend money on Free Software.
One is to buy distros. But having paid for
a distro, give the supplier lots of high
quality feedback. Nit pick (politely and
accurately) about the details that matter
most to you. That helps them decide how
to spend money on development. If you get
no uptake from one supplier, switch to another.
Another good way is to pay developers directly.
The street performer protocol is easy to
implement and _should_ work, if more people
volunteer to pay. My implementation is on
www.regexps.com.
Slashdot Mirror
Damn. I wish I recalled that or could find a jpg on-line. I'm really not into promoting conventional conceptions of sexiness -- but Louise was hot! I think it was the way she exuded a warrior's competence (plus, of course, the skimpy custumes).
Ok -- having found a "fan site" and his official site, it seems Tom Baker is very much alive, and very much grey. So, instead of the origins of Dr. Who, how about a combination of his origins and (gasp!) his fate. Screw perfect continuity with the TV series which is incoherent anyway.
"gobbldygoodk with conviction" -- Tom Baker
-t
Screw douglas adams.
Ya know what I wanna see? A really high budget Dr Who film about his origins, staring Tom Baker who's acting and portrayal-of-this-character-in-particular ability was barely exposed during his stint on the series, yet pretty much defined it for many americans. Man he managed to make gold out of average scripts ("I gave him a blank look"). I'll bet it'd make plenty o' money. Something about the politics of the timelords and the doctor's renegade nature.
Dr Who is a great low-budget tv vehicle -- you can do nearly any cheezy sci-fi plot within its framwork. Nevertheless, there's some neat ideas there, Baker's era stands out among all the others, and I'd like to see more. (Gosh, is baker still around? I'll bet he's all grey now.) (And, ya gotta love all those $3 BBC special effects -- really.)
Make it dark, dark, dark and funny. And make cheezy special effects part of the theme.
And bring in Leela. She was hot and smart (Janus thorn, anyone?). and sarah jane, cause she's cool too and so much a part of the tradition.
children's series, indeed,
-t
So, you put together N processors worth M mflops each and focus only on suitably parallizable computations so then you can claim M*N performance. Yeah? Really? So what?
The average geek is an idiot.
The Arthur C. Clarke quote someone else posted (paraphrased "how many supernovas are industrial accidents") rings true with me.
If you're going to insist on creating exotic matter using very high energy processes in the absense of any accepted theory of what's going to happen, please do it in someone else's galaxy.
Grey goo has got nothing on this.
It's a shame the post with the correct one word answer got categorized as "funny".
Emacs is the right programming architecture for GUIs. The Emacs command set and visual appearence are, obviously, not that great for many users -- but the programming architecture is right.
By being interactively extensible, emacs makes it easy to fine tune an interface while you play with it.
By being lisp based and by having many fine abstractions, emacs let's you do a lot with very little code.
The emacs architecture provides some very fine bits and pieces for achieving excellent accessability features.
By being interactive and self-documenting, Emacs is good at helping people teach themselves to program.
View-tree toolkits, such as underlie Gnome and KDE are inflexible dogs that leaded to bloated yet feature-anemic tools. You know what they're good for? They're good if you have a command-and-control army of drone programmers who can write reams and reams of code. That's why Microsoft apps will remain far more featureful than their free competition until that competition switches to an architecture that works for a society of free individuals.
Yes, it's true: the way you structure your programs has political implications. It defines jobs. It defines the power of managers and project managers. It establishes the degrees of freedom your users have to extend or customize their tools.
Hmm. "attention to detail" was a phrase they used a lot. Ok, sure, these systems need polish.
But -- fuzzy icons -- unified shortcuts -- moving text around by a few pixels. Not _bad_ things to do, by any means. Still.
What about -- "attention to architecture", so that all of these "details" don't turn into infinitely long task lists, so that apps are far better and more consistent at being self-documenting, so that it doesn't take a ton of new code for every little app, so that interactive extensibility is built-in to the core, so that process are managed less horribly....
Somewhat expensive, but well worth it:
http://www.comfortkeyboard.com
It's extraordinarilly configurable and I think you can get it to a state close to what you'd expect of a spherical keyboard.
I have mine with left and right halves widely separated, tented at very steep angles (about 80-degrees), with a kensington track ball sitting in the middle. The keyboard firmware isn't perfect, but works well enough. The trackball stands up to all manner of neglect and abuse.
I've also found it handy to mount a couple of button boxes around the keyboard (I have around 200 keys in easy reach -- roughly half bound to my favorite emacs commands) but my button box manufacturer has been a twit and their firmware is annoyingly flakey, so I don't have a specific recommendation here.
> and for someone as utterly friggin' brilliant as
... I've got this kick-ass business and technology plan here for companies like Red Hat and all the unix vendors.... free software is _good_ for business, and I'm doing my damndest to make things work. (Hey, Scott McNealy, let's do lunch (you're buying):-)
> Tom Lord to be utterly penniless [...] is just
> wrong
Of course, I strongly agree.
> (as in, unable to buy beer, much less pay rent)
I am as happy as one can be under these circumstances to report that, much to my surprise, I was able to buy both this month's rent and this week's beer on the last dribs and drabs of a friend's credit. But, yeah, it's pretty bleak.
But, hey
> [bk is a toy]
It was certainly designed for another era and, judging by second hand reports (e.g., it uses SCCS as a back end), is not the best foundation for today's economies.
arch is far, far better in that regard. Larry has stated a few times that it would take O($12M) for arch to catch-up with bk. I think that's roughly an order of magnitude too large and that the result would be an arch that surpasses bk.
The BSDs have been "way ahead of everyone else" in engineering infrastructure for ten years -- but they aren't "there".
More specifically, the BSD makefiles and the process disciplines observed by the relatively small groups of core maintainers are nice. However, these nice properties of BSD development don't translate easily to other projects; aren't anarchic enough for the role of free software in today's markets; aren't automated enough, etc.
But -- yeah -- the BSDs are pretty inspiring.
Hmm. I have a little paper about where I think the free software business world needs to go to get "there", if anyone is interested. Write to lord@emf.net to ask for a copy.
> Is there a website....
No. I didn't say that commercial support has been found. It hasn't.
> he was under the perception that the so-called
> "community" would donate enough money to allow
> him to accomplish that.
No, I wasn't. The community did keep me afloat for longer than I otherwise would have been, while I worked on getting corporate funding for a small team to finish and polish the hell out of arch.
Now an interesting question becomes: what does the bitkeeper license imply to IBM, HP/Compaq, Red Hat, Suse, Mandrake, and other businesses that depend on the linux kernel?
This event points to a more general problem: the free software business world needs a better infrastructure for all projects, not just the kernel. Now they have one more reason to believe in the urgency of this need.
Who manages the managers?
No -- the right question is: who possesses the circuit breaker. And the answer is obvious, once you consider: who would think it to be a critical tactical and strategic bit of leverage to possess. Hmm. The feds. China. North Korea. India. England. LOTS of people. An embarassment of riches in the buttfuck dimension.
Managment (including execs and principle owners) who don't know and aren't willing to learn about the consequences of their behavior are a scourge upon the face of the earth. Terrorists, basically.
How many people contribute Open Source or Free Software to the world? How many opportunities have been created by the existence of successful, minimally reviewed GNU/Linux distributions for professional cracker community members to quietly introduce bugs? How many sites now run Red Hat, for example? How many of those installations are mission or security critical?
The security problems pointed at (ever so esoterically) in the cited articles are vast, serious, real, and pressing. They are made worse by vendors who persue dubious features and broken, overly complex architectures rather than remembering to KISS and empower customers to differentiate their installations and (especially in a disaster) manage their own source.
The good news: using plenty of available technologies and techniques to reduce the RISKS here can, as a side effect, radically improve the overall quality of the Free/Open Source software being vended these days. We need fewer, but much better features, managed by much better software engineering practices.
That (in my opinion), rather than panicing over security issues, is where our various corporate friends ought to focus in response to this and similar articles.
-t
All the good puzzles are well known. All that you're testing is whether or not someone has read the same puzzle books. If you are trying to make up puzzles of your own, you are probably doing a bad job.
I've never met a competent interviewer. I've met plenty who are just clueless, and some who are asking "will you help us snow the mgt?"
Son, that's Mr. Pussy, to you.
Here's an update about arch and the regexps.com fundraising effort.
A few days ago, I released a GPL'ed package (the monkey directory editor for Emacs) as a fundraiser: rather than post the source or put up a tar bundle or repository, I've been charging people money to send them the source.
To my surprise, that actually worked a little bit. Some people bought copies. Great!
Today I'm trying a new variation: I've mailed out (to the gnu-emacs-sources mailing list) the source for the previous version of monkey, and now I'm offering to sell (still GPL) distributions that have some new features. We'll see.
If all of this works out, one idea I'm considering is to make all of my source available in the usual way (tar bundles, revision control repositories), but to rate-limit traffic from ".com" domains and sell FTP accounts. I think this model can be adopted by many projects, if it works, and that it won't cause any serious problems for hackers sharing code with one another (they just might want to use a non-".com" address for anonymous transfers).
This "service differential for source code" model isn't perfect by some standards. It doesn't force users to pay and it doesn't force customers to spend their money wisely. On the other hand, this model reminds users to pay and implements a well-defined service that they can pay for.
If you like the idea of this model -- that's another reason to support the current fundraiser! Perhaps we can bootstrap a whole new kind of Free Software Business Model.
Yes, other projects need support as well. I regard myself as attempting to:
Is there a way to make money directly for creating new Free Software? In a few cases, those of us lucky enough to get money from users, sure. In the majority of cases, in the future, I think the big companies that use open source ought to come up with funding mechanisms (and fund them!), because that's a good way for them to spend their R&D budget.
We were all young once....(some still are, I guess). I don't particularly recall why that happened, but I'd guess it was because though the (then new) regexp engine tested well on the tests available then, it was too slow on some other cases discovered after release, by users. It only took about another 10 years to get the regexp matcher right :-) You can find the current version in the Hackerlab C library, at
www.regexps.com
I am grateful to supporters for the purchases and contributions received so far.
I'm still a rather far from having enough to stay on-line, but the contributions so far suggest that there is a chance.
The problems faced by arch aren't unique. Whenever I've talked to those more senior engineers who are my friends and who have lots of "open source" involvement, they say "We're hearing this same sad story from a large number of very talented hackers.".
The botttom line: please do contribute to arch. It really is a fiscal emergency and your support is much appreciated. But in addition to sending support, please also send a short, polite note to your favorite budgeted manager or exec at an open source or free software friendly company. Point out to them that you are doing their job and spending money in a way that will benefit them. Ask them to be more proactive in supporting free software researchers, including working on their host organizations to establish some winning policies in this regard.
Um, hey -- I think I'm now obligated to all your reading skills into question ;-)
It's a FAQ, not a paper. In other words, its designed to help orient readers to the design space and give them a staring point for research and comparison. I assume that the FAQ's readers are smart enough not to try to use the FAQ as a CS textbook.
Second, what I've tried to say in the FAQ is not that databases are overapplied (that's for another discussion) but rather that arch's standard-file-formats and ordinary filesystem tree orientation resulted in a very tiny, simple implementation that nevertheless has many of the desirable semantic and performance characteristics people often presume require a database.
That second point isn't some loopy overgeneralization about databases: it's an observation about how the implementation "came together" around simple file formats.
But yeah, thanks for the reminder that when we really do get around to having the "proper role of BTREEs" debate, that, in light of all the accumulated wisdom on the topic, I'd better speak very carefully.
There's nothing wrong with getting a bug report that includes some money -- that's fine.
The problem is that people can only make enough money to fund development that way if:
- (a) their program is buggy or missing critical features
- (b) their program is commercially important
to users already
- (c) there's no Cygnus-type company to compete against
- (d) the developer only wants a minimal
hourly rate for fixing bugs -OR-
the developer is so uniquely
qualified to fix the bugs that he
can charge a huge premium compared
to other solutions
Let's look at those from my perspective:- (a) I don't like to write the kinds of program
that are perpetually buggy and always need
fixing or extending. I don't think there
should be financial incentive for doing so.
(Looking at the documentation and development
priorities of some commercially hot projects,
I think one can see evidence of that
incentive at work, but its difficult to
try to discuss that objectively without
stepping on people's toes.)
- (b) I like to use my skills and broad
exposure to design new kinds of
software solutions to problems that
most people don't fully recognize
yet. In other words, much like a lot
of programmers working for MS, I like
to make it my job to work on programs
that will start to be important a few
years down the line. It would be premature
to try to support advanced development like
that on the basis of any kind of
bug-fix or feature-development contract.
- (c) Well, I'm not too worried about a Cygnus-type
company wanting to "steal" my R&D business,
but such companies still pose a problem.
Suppose I thought "Well, I'll just self fund
the intial development, then start my own
support business once the project takes off."
That would be unrealistic. The more likely
outcome is "I'll self fund initial
development, then some company like IBM or
Suse will get the support contracts."
The leadership of those companies has been
so (from my perspective) ineffective about establishing any kind of
R&D funding for open source, that I find
myself seriously questioning my loyalty to
the GPL and wondering if there isn't some
better license that would let individuals
do business with my code, but tell those corps to go
screw themselves.
- (d) Ultimately, bug fixing and support for
open source is a low margin business
(meaning you may as well think of it as a
minimum wage job) because there is little
or no barrier to entry for someone that
wants to compete against you. The only
winners in this kind of business are
big companies who manage to achieve
efficiencies of scale, and perhaps one
or two vanity companies, who's prestige
supports payment well above market rates.
In summary, bug fixing and support are limited, lousy business models that do little to help creative free-agent developers or otherwise advance the open source R&D. This has nothing to do with what you termed "temperment" -- it's a serious problem and we're seeing a dismal lack of leadership from the execs who are in a position to do anything about it. Since those same execs tend (just as a general, industry-wide trend) to resource starve their in-house projects, I don't even hold out much hope for a sudden swell of grass-roots support for open source R&D funding from the ranks of technical managers. It's an alarm I keep trying to sound: redmond (to name just one example) hasn't stopped doing R&D. And when those companies use the label "R&D" -- it isn't just for tax purposes. They really do pay quite a bit to have people form little intellectual communities, trade ideas, and develop new systems in an exploratory mode. They really do (judging from their output) seem to have the goal of obsoleting the entire generation of technology to which pretty much every piece of open source code belongs, and, at least from a technical perspective, they have more than enough brain power to succeed.That's crazy. Businesses are already extremely efficient at providing new features and support. They are experts at those kinds of contracts and open source volunteers can't compete against them in such a simple minded way.
The real funding need in the open source world is sustained, long-term funding for creative, exploratory research and development. We don't need customers who want to buy "features" or "support" -- we need customers who want to simply PAY US TO HACK on new and interesting projects that may be too new to help many customers directly today, but that will help the open source world evolve tomorrow. It's because we in the open source world don't pay people to "just explore" that Bill Gates gets to say the GPL is bad for the industry and unamerican and that fascistic copyright protections are a necessity.
I think there are at least two good ways to spend money on Free Software.
One is to buy distros. But having paid for a distro, give the supplier lots of high quality feedback. Nit pick (politely and accurately) about the details that matter most to you. That helps them decide how to spend money on development. If you get no uptake from one supplier, switch to another.
Another good way is to pay developers directly. The street performer protocol is easy to implement and _should_ work, if more people volunteer to pay. My implementation is on www.regexps.com.