[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

To package or not to package?

Dear all,

I jump in the discussion to react to Zack's point of view about

> However, in many cases, free software developers tend to reinvent the
> wheel quite often (so two apps can share the exact same goal and have
> very similar designs, the only difference being that one is of less good
> quality than the other). It's generally a bad idea to package both
> apps in this case, because it increases the workload, reduces the
> users-per-package ratio, etc.

In the field I decided to cover, I took another approach: packaging A
but not B biases the competition towards A, although I do not feel able
to make a choice between A or B which would be logical and fair.
Therefore, I try to cover the field as extensively as possible,
packaging DFSG-free software by default and telling the users that
non-free software will only packaged upon request.


With all packages performing the same task being equally available, I
expect natural selection to happen based on other criteria: popularity,
speed, accuracy, simplicity.

With the expected increase of popcon after Etch release, I am eager to
monitor the ecosysem and test in real wether my expectations were naive.

Have a nice day,

PS:  Feel free to CC as I am not subscribed.
PPS: The web archive provides the message-id, to set In-Reply-To
     correctly by hand.

Charles Plessy
Debian-Med packaging team
Wako, Saitama, Japan

Reply to: