Re: [ba-ohs-talk] Re: Rethinking Licensing
On Thu, 16 May 2002, Paul Fernhout wrote: (01)
> Essentially, it seems as much as Doug originally said OHS would be open
> source, it seems to me this particular community is having trouble
> making that commitment in actuality (i.e. offering actual code and
> content for use under a specific license) because most of its members
> and core leadership have historically implicitly or explicitly expected
> grant money to directly fund the work and its future enhancement, and
> many other participants are here thinking they can make money
> proprietarizing the result somehow (or integrating their current
> proprietary approaches into it). Otherwise "permission to use" would
> have been resolved two years ago. (02)
As someone who just raised the spectre of explicit granting, I'll
go off on a somewhat related tangent: (03)
- I'm with Mike: given a pocket-guide spec I could and would
code. In fact, to a certain extent, the work I'm doing with
Kathryn on coming up with access structures and mechanisms for
the unrev-ii archive is directly applicable to some of the OHS
goals. The rest of my graduate work is likely to be focussed
around that sort of thing in combination with development of
tools for visualizations of document similarity. The point: I'm
only able to do that work as a result of the loans I get from the
federal government and the funding I get from the school.
Unfortunately, as Paul has pointed out several times, the
future availability of that work is still up in the air because
of licensing confusion. I have an appointment tomorrow to start
addressing that issue. I don't expect that to be fun. (04)
- Fat source-available projects like Linux and Apache have been
driven by funded people. Linus got Linux off the ground while a
student in Scandanavia, home of aggressively enlightened socialism.
For most of the first few years of Linux many of the people
actually making substantial code submissions either never slept
(Alan Cox) or were university students or staff (Dave Miller). (05)
The development of Apache was essentially funded by the
companies that "owned" the system administrators that were
frustrated with the development process of the NCSA httpd. They
collaborated, on company time, to fix bugs leading to a fork so
they could get their "real" jobs done. I can tell you that in
my several years as a system administrator an extremely large
portion of my time was devoted to the upkeep of available source
products because those products were essential to the services
of the companies for which I worked. (06)
I agree that a project like this, with what amounts to a
spiritual leader as relevant and cool and Doug E, ought to be
thronged with developers. I can tell you, as someone who comes
into this world from the free software development world, there
is a definitely a problem of what amounts to marketing. This list
sounds, for the most part, like a bunch of old men sharing links
and complaining about licensing. I say that with a great deal of
respect: you guys are _extremely_ smart, have a lot of very good
ideas, have a good sense of what is good, constantly amaze me
with the depth and bredth of knowledge you can bring to bear on
subjects. However, there is no consistent or clear vision of what
is being attempted here, no leadership, no milestones and very
little code. There are developers here and presentations of the
things they are developing, but they aren't integrated into a
starting point of any sort. (07)
Much of the intro classes in my program at school have been
related to concepts of human-centered computing and the like.
Stuff that I've found very annoying because it focuses on
creating software tools that are easy to use and easy to learn.
This is an admirable goal, but the literature is so focussed on
this aspect that little time is spent on questions such as "what
are we trying to accomplish? what tasks are we attempting to
augment or automate? why? how? is it necessary?" Being in that
context has caused me to view most failed software ventures as
not failures to create something but instead failures to do
something worth doing or put that something in the right context.
Cars are not easy to use in any absolute sense, despite being
canonical objects in usability literature. They are instead
culturally accepted; they are a part of our consciousness, made
that way because the need to get across town in a hurry was
created in a symbiotic co-evolution between technology and the
society that created it. The same could be said for email
clients. All email clients suck, some less than others, but they
are considered easy enough to use by a large segment of society. (08)
I think the need for an OHS is far too abstract to be especially
motivating in any concrete fashion. Instead of motivating people
to code, it motivates people to talk about what's wrong with IP
laws, food, and how we need better systems for representing
knowledge in graphical formats. Others have suggested that we
focus on a particular use case (Jack has mentioned education, I
think this is still too abstract); something like that may give us
a place to hang something. I'm not sure. (09)
What I am sure is that there is a cultural barrier to our
success. There is not an economic problem, nor a talent problem.
We have the people, either very present or lurking, to make
something happen but we do not have the oomph. Is it a question
of need (do we really need to get across town in a hurry?)?
Is it a question of focus (what are we doing, really?)? (010)
I've hesitated to say anything before now because I did not feel
it was appropriate. Perhaps that's the key: there's a strong
sense of insidership here, without much mentoring. I've been
around long enough now to realize this is not intentional but it
still represents a strong barrier to participation. I feel like I
have to think really hard before I post something: that is
_entirely_ antithetical to the volunteer software development
scene (in my analysis). (011)
We are, however, past the golden age of software volunteerism or
nearing the end (to my eye the OpenSource(TM) movement killed it.
I'm happy to discuss that, but this is not the place for it (so
email me separately if you are interested)) so having a cool idea
and enough cool code to show to potential helpers is no longer
enough. There needs to be organization, focus, leadership, goals,
distribution of tasks, etc etc etc. Infrastructure. In some ways
that is truly unfortunate. (012)
I wonder if it might not be worthwhile to do the following to
improve our infrastructure: (013)
- Create a ba-ohs-devel list where specifications and code can be
discussed in a focussed fashion, leaving talk for things like
licensing, sharing of links, tool ideas, implementation
generalities, philophical meanderings related to an OHS.
unrev-talk would be the place for still larger issues. A little
rigorous self-moderating (in the "hey, move this to to unrev"
sense) would be good.
- Since we've had the "I think it should be GPL" statement from
Doug, go ahead an put up an anonymous CVS server on
lab.bootstrap.org, or somewhere similar, assign a CVS
keeper (Eugene?), and starting diddling.
- Proceed post haste, _regardless of licensing issues_ (hoping
for good resolution) thus demonstrating our commitment, with
reevaluating and refining the OHS spec, enculturating people
along the way, and discovering tasks and milestones. (014)
But that won't be quite enough. There's more, the cultural thing.
I don't really know what that is. Any ideas? (015)
--
Chris Dent <cdent@burningchrome.com> http://www.burningchrome.com/~cdent/
"Mediocrities everywhere--now and to come--I absolve you all! Amen!"
-Salieri, in Peter Shaffer's Amadeus (016)