Re: Compatability with FreeBSD Ports

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Sat, 13 Aug 2005 16:07:14 +0100
Hiten Pandya <hmp@xxxxxxxxxxxxx> wrote:

> Chris Pressey wrote:
> > 
> > Allow me to submit a rebuttal (don't take this too seriously ;)
> > speaking from a theory of open-source as a self-organizing system of
> > individuals working strictly on their own time and strictly for
> > their own interests:
> 
> Not taking it too seriously, just how it should be. :-)
> 
> The operative word there is theory,

And, I should stress, not necessarily a theory that I subscribe to. 
Just the most prevalent theory for "why open source works", as described
by writers such as Eric S. Raymond and Richard P. Gabriel.

> as long as you keep that in mind and 
> come back to the practical world.

My issue is that the theory doesn't seem to match practice very well.
If the practice really is working, then we need a new theory.

> It is important to notice that when
> resources are scarce, it is important to prioritize workload.
> 
> If we were to priotize operating system features over core system
> bugs, we  would be kidding ourselves into thinking that we are
> building something  stable and reliable.  Same analogy applies with
> external packages as well.
> 
> > 
> > Why should I fix Gnome if I don't use it?
>  >
>  > Why should I scratch an itch that I don't have?
>  >
> 
> If you were a user of DragonFly, you don't have to (careful choice of 
> words) fix issues for other people, but as a developer of DragonFly,
> in my  opinion, ones responsibility is to fix things of priority,
> provided one  has the time and energy.

And the familiarity.  With the notable exceptions of you, Matt, and
Joerg, most developers are restrained to a single subsystem or layer.

> Of course, I can't impose this type of thought on everyone, but this
> is  what I think how things should be done.  Matt follows this same
> approach  if none of you have noticed before, unless it gets
> delegated. :-)

Fair enough (but see below.)

> > If lots of users use Foo, then lots of patches to get Foo working
> > will come in, and Foo will be well-maintained.  If no users use Bar,
> > then no patches for Bar will come in, and Bar will rot.  Problem
> > solved - the
> 
> Here you are assuming that users of 'Foo' have any former development 
> experience.

Yes, because the classical "zillion-eyeballs" theory of open source
would seem to require it.  This was the original environment for
open-source, as I understand it: each user was also a developer.

Nowadays, what you have is a small class of people who put in a large
amount of effort to create systems, and a large class of people who reap
the benefits of those systems while only putting in a small amount of
effort (or none at all) towards their creation.

How does this work economically?  Why does the small class do this for
the large class?  What do they get in return?

I guess each developer can only answer that for themselves.  But I'm
still curious.

> > packages that are well-maintained are exactly the ones that are in
> > demand.  What need is there for a list?  How is it not just another,
> > unnecessary level of organization on top of something that already
> > organizes itself automatically?
> 
> There is no such things as automatic organisation.  Someone has to 
> organise so that others will align themselves accordingly.

Well, a biologist might dispute that, with the typical example being a
termite colony.

> I am NOT implying that we require a DETAILED list of packages, but an 
> overall vision of priority so that development resource, time and
> skill  are applied to the rightful place.
>
> Priority of stabilisation and package fixing is more important than
> adding  features.  I am sure a lot of people will agree with me here.
> 
> 			-Hiten

Back to the practical point of view... my two cents:

All the lists, prioritization, and organization in the world won't help
if there isn't someone willing to put in the effort; someone to take on
"package stability" as their task, like how Max has taken on make(1) or
how Sascha has taken on syscons(4).

A vision is great - critical, in fact, as a sort of social contract -
but only insofar as it attracts people who are _already_ self-motivated.

I'm sure there are several people who will be willing to step up to the
plate for package maintenance, regardless.

And I'm sure that when popular stuff breaks, they'll be the first to
know.

And, if they need lists and other administrivia to help them track it -
well, they can make them.

And if the project wants to help them make those things, it should give
them tools to do so.

(Whatever happened to Bugzilla?)

-Chris