Re: duprkit User Repository
On Mon, Apr 08, 2019 at 12:57:56PM +0000, Mo Zhou wrote:
> On Mon, Apr 08, 2019 at 08:36:45AM -0400, Roberto C. Sánchez wrote:
> > On Mon, Apr 08, 2019 at 11:02:35AM +0000, Mo Zhou wrote:
> > In such a large community of volunteers it may not be enough to propose
> > something that is only marginally better because the cost (even just in
> > cognitive terms) and effort required for so many individuals to overcome
> > inertia is relatively high.
>
> Linus said that "Talk is cheap, show me the code."
> Now I have shown the code and nobody read that.
>
> The single-file format is not mandatory, and two convertion tools
> enables zero-cost convertion:
> https://github.com/dupr/duprkit/blob/master/bin/fold
> https://github.com/dupr/duprkit/blob/master/bin/unfold
>
> And the prototype implementation is compatible to the traditional debian/
> directory. See https://github.com/dupr/DefaultCollection/tree/master/rover-traditional
> for the example.
>
> BOTH single-file format and traditional format are supported. People
> could choose and use what they like.
>
> I admit that I'm quite fond of the proposed single-file format, and
> hence didn't mention and compatiblity with traditional format in design.
>
> > I am not trying to discourage you from your effort, but rather advising
> > you that the chances of success would improve if you address the
> > principal obstacles to adoption in a holistic way. (As I already
> > pointed out, your current approach misses a great deal.)
>
> What else can I do? Both traditional and single-file formats are
> explicitly supported now.
>
Two suggestions:
- Stop claiming that what you propose is "zero-cost", "only 1 second of
work", etc.*
- Find the individuals who currently experience the greatest pain
associated with the problem you are trying to solve and whose pain is
relieved by your solution. Get them to adopt it. If it works as well
as you say it does, they will be enthusiastic adopters and will have
no problem telling others, in concrete terms, how much better your
solution is than whatever the current situation is.
* Even in a perfect world, nothing is "zero-cost." To a community of
contributors whose purpose it is to build an operating system
distribution a deep understanding of the components that compose the
system and the components used to build the system are effectively a
requirement. Thus, if I came along and said, "here, I have a drop-in
replacement for utility 'foo', and I call the replacement 'bar', and
it supports all the same options as 'foo' so that you can use it
without having to think about any differences" I would still expect
that there would be a need for me to convince potential adopters that
things really work that way. Experience tells us that even "drop in"
replacements for things are seldom that "perfect" when it comes to
compatibility with whatever they are replacing.
Regards,
-Roberto
--
Roberto C. Sánchez
Reply to: