[Bese-devel] Introduction and questions...
Adam Jones
ajones1 at gmail.com
Fri Nov 11 02:43:58 UTC 2005
> > Actually I think drew is on the right idea here. Someone (I think it
> > was paul graham) commented on how an initial launch of a product that
> > is not ready for use will lead people to not try additional versions.
>
> Eric Raymond calls it the Cathedral method in his book the Cathedral and
> the Bazaar. As a coincidence I started reading it yesterday. He
> describes how he and most hackers used to believe in what you and Paul
> Graham say, but that he changed his mind after observing the Linux
> development model. Instead of seeing the bugs as problems you have to
> hide from users, by only releasing stable versions, it is an attitude
> more like "If you have more eyes all bugs are small". He calls the Linux
> mode the Bazaar, and has a whole chapter with arguments why the Bazaar
> method is better. Paul Graham is a hero and a guru, but I don't think he
> has much experience from open-source projects [*]
I think my idea tries to take the best of both. The problem with the
bazaar concept is that opinions have inertia. Someone who sees a
half-finished initial version of a piece of software will hold onto
the opinions they form of it for a long time, and will not change
their assesment as quickly as if they had first evaluated a more
finished product.
My point is that development "in public" is a great idea, distrobution
is not. Public distribution ensures that people with neither the time
nor the energy to even debug their installation of your half-finished
code (much less help you fix it) see and do not like your project.
>
> > Although it is still not at a full release (0.14.3 with other packages
> > even lower at the time of this writing) ruby on rails is usable now. I
> > mention this because lisp on lines fits in the same product space for
> > lisp as ruby on rails does for ruby. When anyone sees it they will
> > draw comparisons between the two, and if LoL does not have the same
> > kind of functionality that RoR did at release they will make some bad
> > assumptions.
> Is this even a problem? You can't win everyones heart. But *if* the goal
> is world-domination there is an even bigger problem if things take too
> long time. Especially if you compete with a project that is usable now.
I would say it is a problem simply because people are going to draw a
comparison between the two. Anyone new to both platforms will look at
LoL and see a project that is nowhere near what RoR is at the moment,
and go for that. Some degree of interest is necessary to sustain any
open source project, and a little forethought into the management and
timing of releases now will secure that interest later.
>
> >
> > I would say make the code available by request. That allows the people
> > who really want to play with it (i.e. enough to send out an email) to
> > get to it, and keeps anyone who is just browsing from getting a bad
> > idea. It allows more eyes that are willing to help fix the problem to
> > look at it.
> It's a compromise. I can understand that if you develop something clever
> it can be distracting to have lots of people asking questions,
> commenting and asking for new features and so on. But there is also the
> possibility that someone may bring good stuff to the project or solve
> one or few bugs or add some documentation or find a corporate sponsor or
> whatever.
This is why I suggested keeping it open by request. It allows some of
the benefits from a fully open project, but keeps project control more
firmly in drew's hands with less management overhead (i'm sure he
would like that)
In the end it is up to drew, who is probably too busy coding to watch
us plan out his project. =)
>
> /Henrik Hjelte
>
> [*] What is happening with arc anyway, the new better Lisp from Paul
> Graham? Still preparing for the grand opening I guess...
At times I wonder if he just trots it out whenever it seems like
someone is starting to put together a new lisp. Really though
designing a new language is a tough thing, trying to "beat lisp" with
it is even more so, and paul graham comes across a somewhat of a
perfectionist to me, which will slow down a project even as it makes
things ultimately better.
-Adam
More information about the bese-devel
mailing list