[Just adjusting the subject line to better reflect the discussion,
not to change the subject.]
Nik Frengle expressed the dilemma pretty well in a recent CODEJ [1]
presentation.
I asked him about device characterization, and whether Intadev's [2]
mInt had much in the way of diagnostics about content that wouldn't
play on certain idiosyncratic phones.
Nik replied: "It would take three people working full-time to cover
all the issues." (My paraphrase.) That might overstate the situation,
I don't know -- I'd ask those Nooper [3] guys. It is a problem,
though.
Curt makes a point about licensing that I more-or-less agree
with: for stuff like this, BSD-style licensing makes it easier to
commercialize, if commercialization is the way to go in the long
run. Is it? It's a good question, but I won't take it up here.
As an open source pundit, I am at best the ne'er-do-well
nephew [4] of the Grand Old Man of Open Source Punditry,
Eric S. Raymond [5]. However, I think I can at least
comment on Nick May's proposal in the light cast by Hizzoner
GOM OSP ESR.
----
Here's a summary of ESR's "The Cathedral and the Bazaar" [6]
rules of open source development, with my commentary on how
they might apply to keitai device-characterization database work.
ESR: "Every good work of software starts by scratching a developer's
personal itch."
Your chances are far better if you're writing something you want
to use yourself. Altruism and ego are secondary motivators at the
outset. They won't get you very far. Forget purity or self-
aggrandizement. For motivations, go with "I did this frob
'cuz I wanted my cool game to work, a game I wanted to play,
and the development was too messy without some kind of tool
I didn't have, and needed to write." (Believe it or not, this is
the origin of Unix: it started as part of a video game develop-
ment system for Spacewar at Bell Labs.)
ESR: "Good programmers know what to write. Great ones know
what to rewrite (and reuse)."
There's almost certainly something out there to use as a starting
point. Ask around. Somebody's gotten sick of hacking on
what they have, see no future in it for them, at least not by going
forwared alone, and will give it up freely.
ESR: "Plan to throw one away; you will, anyhow." (Fred Brooks, The
Mythical Man-Month, Chapter 11)
You Don't Know What You're Doing Until You've Tried to
Do It and Made a Hash of It. Open source has the gift of time --
you can fail and it's OK, since you're not about to get
your eyeteeth knocked out on the sill of an upward-looming
market window. Fred Brooks' OS360 project wasn't
so lucky. Nor were tens of thousands of projects since
then.
ESR: "If you have the right attitude, interesting problems will find you."
And what is that attitude? Well, most real inventors are
improvers, and are motivated by a love of tinkering, as
well as a desire to do something cool, a thing that maybe
other people will like and find useful. Open source is
mostly 'tail-light chasing', reinvention of wheels, but that's
OK: it's still process motivation.
ESR: "When you lose interest in a program, your last duty to it
is to hand it off to a competent successor."
Cases in point:
I've been researching e-mail archive threaders. Keitai-l
uses hypermail, which was briefly orphaned by pipermail
and MHonarc. Now it's back, fully supported, and those other
two are the orphans.
Open source development both starts and continues
as a series of handoffs.
ESR: "Treating your users as co-developers is your least-hassle
route to rapid code improvement and effective debugging."
This is a real constraint, with all the handsets we have here
in Japan, and all their features and foibles. Must Find Users.
Can you scratch your own itch, and scratch the itches of others
at the same time? Initially not, but eventually you have to.
ESR: "Release early. Release often. And listen to your customers."
Pretty important, I'd say. "It's not ready yet" is, except in
the most embryonic phases, a pretty lame excuse.
ESR: "Given a large enough beta-tester and co-developer base,
almost every problem will be characterized quickly and
the fix obvious to someone."
I.e., Massively Parallel Debugging. "With enough eyeballs,
all bugs are shallow" is how someone else put it. This is
not a rule, but an outcome of applying the "release-early-
often-and-listen" rule. If you're not getting any feedback,
you're getting important feedback: the world's telling
you it's not interested, and you should just abandon ship.
Keitai holds unique promise of offering good massive
parallelism, lots of eyeballs, if you can sign up your
developers/beta-testers to keitail-email addresses -- just send
the URL for your latest issue to their phones, and they
can check it out it wherever they are, even if they can't fix it.
ESR: "Smart data structures and dumb code works a lot better
than the other way around."
Data-driven programming styles are not old-fashioned.
A database of keitai capabilities will need a lot of code
to be truly useful, of course, but it's the architecture of
the database that's the real architecture.
ESR: "If you treat your beta-testers as if they're your most
valuable resource, they will respond by becoming your
most valuable resource."
A slight repetition, but places the focus where it should be.
ESR: "The next best thing to having good ideas is recognizing
good ideas from your users. Sometimes the latter is better."
I'd put it the other way around, personally. Keitai
is such a consumer phenomenon, I'd put the
emphasis on getting feedback from users who aren't
programmers.
"Often, the most striking and innovative solutions come
from realizing that your concept of the problem was wrong."
This is when you think about throwing things out, of
course.
ESR: "Perfection [in design] is achieved not when there is
nothing more to add, but rather when there is nothing
more to take away." (Antoine de Saint-Exupery)
Device characterization and device-dependent
content management will, necessarily, be something
of a snowball. But a revelation might come, and,
being an open source revelation, it might not
fall prey to what a commercial-software programmer
friend of mine called "the typical management reaction
to outbreaks of truth and beauty." You really
can back off and rewrite, stripping away that
cruft.
ESR: "Any tool should be useful in the expected way,
but a great tool lends itself to uses you never expected."
Not much to comment on here, but at least it
tells us to avoid expectations.
ESR: "When writing gateway software of any kind, take
pains to disturb the data stream as little as possible
-- and never throw away information unless the
recipient forces you to!"
Possibly a guideline for keitai-web infrastructure
and transcoding.
ESR: "When your language is nowhere near Turing-
complete, syntactic sugar can be your friend."
A deeply geeky observation that translates to:
don't fall prey to that 'we need a whole new
programming language' temptation (I call this
one of computer science's 'manhood issues'),
but making databases more human-readable is
otherwise A Good Thing.
ESR: "A security system is only as secure as its secret.
Beware of pseudo-secrets."
[Not at all sure of how to apply this one, not
even sure I understand the original context.]
ESR: "To solve an interesting problem, start by finding
a problem that is interesting to you." [Restatement of rule 1]
Well worth repeating.
ESR: "Provided the development coordinator has a medium
at least as good as the Internet, and knows how to lead
without coercion, many heads are inevitably better than one."
This is ESR anthropologizing again, mainly a bow toward
Linus Torvalds. In fact, there are long-term viable open-
source projects that are run in a rather off-putting monarchical
fashion, and they survive anyway, somehow. The real
point: leadership in open source is mostly good librarianship
and relatively little force -- there's already so much
goal-alignment that force isn't much needed. Otherwise
the thing wouldn't have happened in the first place.
----
A final note: open source development is really more
like "open source *maintenance*" -- it's not really a
methodology for starting from scratch. (Some, such
as Scott McGregor, have nevertheless defended free
software as being at CMM level 3. [7]) I.e., you have
to start with something, and that means some methodology.
In CMM terms [8], you basically have to start at level 1:
hacking up something by yourself, or with a few friends,
very informally. And you can't skip steps.
So it all starts out closed-source, if only by default. Linux
itself basically started from 386 motherboard diagnostics
that Linus Torvalds was paid to write. He then
noticed he'd written most of a kernel in the process,
and knew what kind of kernel he wanted it to become.
The rest is history, of course. But those who don't learn
from *prehistory* are condemned to repeat it, forever.
-michael turner
leap@gol.com
[1] www.codej.org
[2] www.intadev.com
[3] www.nooper.com (No, this is NOT a plug!)
[4] http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
(Search on "basically wrong-headed")
[5] http://www.tuxedo.org/~esr/
[6] Ibid [4]
[7] from some usenet software engineering discussion group
in the early 90s (Scott McGregor: http://www.prescient.com/mcgregor/)
[9] http://www.sei.cmu.edu/cmm/cmm.sum.html
----- Original Message -----
From: "Curt Sampson" <cjs@cynic.net>
To: <keitai-l@appelsiini.net>
Sent: Sunday, February 24, 2002 3:13 PM
Subject: (keitai-l) Re: western phone, imode sites...
>
> On Sat, 23 Feb 2002, Nick May wrote:
>
> > I would like to start getting on top of this problem, preferably in a
> > coordinated way. Are other list members interested in being involved in
> > creating some kind database of phone capabilities that takes into
account
> > the new western phone (German/Dutch imode being just the start) that
they
> > are prepared to release under the GPL or LGPL.
>
> I might be interested in hacking on some Java code to help deal
> with this sort of thing.
>
> However, I'd suggest that GPL would be bad, since GPL'd code
> generally can't be included in commerical products that are shipped
> to others. (Even if you don't mind releasing parts of your source,
> licensing just one bit of code from another vendor can mean that
> you can never use any GPL'd code because the other vendor's license
> is incompatable.) I'd suggest that the BSD license (with the
> advertising clause removed) is a better way to go.
>
> Personally, I just put my code into the public domain and be done
> with it.
>
> cjs
> --
> Curt Sampson <cjs_at_cynic.net> +81 90 7737 2974 http://www.netbsd.org
> Don't you know, in this new Dark Age, we're all light. --XTC
>
>
> This mail was sent to address leap@gol.com
> Need archives? How to unsubscribe? http://www.appelsiini.net/keitai-l/
>
>
Received on Sun Feb 24 13:48:33 2002