Compatability with FreeBSD Ports

Hiten Pandya hmp at
Sat Aug 13 08:07:14 PDT 2005

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, as long as you keep that in mind and 
come back to the practical world.  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.

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. :-)

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 

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.

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.


More information about the Users mailing list