develooper Front page | perl.module-authors | Postings from November 2011

Re: The CPAN Covenant

From:
Linda W
Date:
November 28, 2011 10:08
Subject:
Re: The CPAN Covenant
Message ID:
4ED3CDFF.3000608@tlinx.org
Jonathan Yu wrote:

 > I try to stay out of these discussions (*cough* flame wars), but here
 > goes...
 >
 > The relationship between CPAN and the Developer is bi-directional, no
 > doubt.
 >
 > As an organization, CPAN can, as it chooses, decide to do what you are
 > suggesting, remove software or boot a Developer. However, I do not
 > believe the prerogative of CPAN is to do so, since it would reduce the
 > utility of CPAN as a whole - the point of CPAN, and the advantage it
 > confers to Perl over other languages, is a central location for all
 > software, that is installable in a very straightforward manner. This is
 > something that Java is only recently starting to attempt to replicate
 > (e.g. with Maven).

----

   Do not misconstrue my words.  I only said that CPAN would apply such a
function to a module that doesn't meet quality standards.  I.e. It Does
NOT, as you say install in a "straight forward manner", and often doesn't
install on any platform as it is so outdated, the interface and or programs
it was based on either don't exist, or have evolved into something
completely different.


   In that case, such modules on CPAN are worse than DEAD WEIGHT, they don't
just take up space.  People, like you say, come to CPAN for 'modules that
install in a straight forward manner'.   If the module fails in that
regard, then the module has no place on CPAN.


 >
 > On the other hand, a Developer, as he/she chooses, can decide to accept
 > or reject patches, etc. The nature of open source is that Developers are
 > often too busy with other work (read: putting food on the table) to
 > perhaps commit to tracking down some very difficult-to-find (or even
 > unreproducible) bugs. On the other hand, as a user, you can leverage the
 > advantage of open source - the freedom to see and to modify the source
 > code - to benefit both yourself, and the community-at-large, by
 > submitting patches.

----

   The  person who I responded clearly stated that unless I was willing to
pay to make it his highest priority, then my patches would be given lowest
priority.  Personally, I don't like that attitude nor do I believe it
belongs on CPAN which is supposed to be about you **giving** to the
community (not charging them for it!)

   In fact, I would propose that anyone who even raises that option in order
to even accept a patch should be banned from CPAN (maybe not on 1st
offense), but CPAN is suppose to be like perl, free as in beer...etc.

   It's a different matter, if the user wants customization.  But if it
doesn't work out of the box on its intended target, then there's problem.

   Which brings me to another point.

   If a developer can only support or is only willing to support some subset
of patches, then then their name space has to be subdivided by architecture
-- i.e. You can't reserve exclusive rights to a top level name that only
supports 'windows', 'mac',  or 'linux' (or whatever).  You would GET access
to the top level name as part of supporting the arch specific name, but
consensus must be agreed to make a change to the top level that would
require changes to other architecture specific levels.

   That *doesn't* mean that EACH platform must support all of the same top
level features -- but what is supported on each platform my be clearly
spelled out and easy for users to understand.   If the differences are
large between platforms (more than 10% maybe?), it should be spelled out in
emphasized print near the beginning of the top level documents: "depending
on your platform features may  or may not be implemented or supported"...
see arch-specific details for more information about what is supported on
your platform.

   Further, this implies the top level interface can be **added** to for
functions NOT supported by other platforms and sub-functions may be added
to existing functions.   But existing behavior should NOT be changed.
(Backwards compatibility is important, but cross platform behavior can't
always be supported in every circumstance).

------------------------

   I'd further divide those modules up into the level of support (as
measured by severity of bugs filed), and a separate metric: breadth of
coverage, as measured by 'demand'...

------

   That way one could ask searches to only return modules supported on by at
least <two or more of this list> && >two or more of this list> and && 4 or
more of this list... allowing one to know there is some level of support on
the other platforms, and a fair amount in a platform you need right now ..
(OR specify 1 platform...whatever...queries can be flexible!)

 > If you feel that the patches are taking too long to be applied, or they
 > are being rejected outright, it is your prerogative to fork the project.
 > There are many examples of this on CPAN already - e.g.
 > MooseX::Types::DateTime::ButMaintained.

----

   Which is the right idea, but Bad for perl/cpan, since the first thing
people will find in current searches is the higher level module.  I also do
not want to see 'Maintained or not maintained' on CPAN.  as unmaintained
modules (that have outstanding bugs/problems), have no place on CPAN.
(this implies that a module that adds 2+2 and written 10 years ago, and
still works today wouldn't be affected!)...

 > It should also be noted that some projects that appear to have been
 > abandoned have had their maintainership rights assigned to others, who
 > have thus taken over maintenance of a package. You may contact the PAUSE
 > Administrators to discuss these cases.

----

   Red Herring, since I wouldn't suggest (especially at this point that such
decisions be enforced and put into place without the interaction and
concensus of 'some group' of current CPAN-lib/site maintainers, or some
*plurality*, of some equivalent mailing list.  People who are
'obstructionists' on mailing lists will be ignored.  If they can't come up
with concrete, engineering based decisions to block something, vague whine
about 'well I dunno, i think this should be thought about for a years,,, it
might cause problems in <insert corner case>...   Simple majority stuff is
'bad', (whether it's > or < 50%).


   **Ideally**, solutions that allow the old module /behavior to be invoked
through compat flags would be idea IF there are a significant number who
feel that should stay -- BUT if it is broken -- there's no point.

 >
 > There are many other options that do not involve flaming the developer,

---

   Flaming the developer?  I would hope that would never happen.  Perl is
rather agnostic in that regard as well as are compliers etc (though I admit
to the occasional pang of resentment aginst getting 20-30 errors for a
missing 'semicolor'... that really seems like a flame at times!).

   Something works or does not.  There is no 'flame' in that evaluation.
The flames come when someone wants something fixed, and someone else
doesn't, won't, or can't fix it, but won't let anyone else do so -- then
tension arises between competing goals and flaming can arise.

 > who contributed their work to the CPAN for the public interest, free of
 > charge.

---

   And the guys standing on the free way exits often will start cleaning
your window "for free in the public interest as well"...  so?  Did I ask
them to?  Doing things out of right intentions only means your a good
person -- but it doesn't mean your are actually doing what is best for the
community or fulfilling the need(s) of the community.  It's sad when
occurs, but CPAN can't afford to be a refuge for those who don't have the
right idea or right chops.  They need to be gently acknowledged, that there
stuff isn't meeting the needs of "60% , 10%, 80%,...whatever of the users,
and that they need to open up that 60/10/80% of their code/namespace to
someone who is willing to support that segment.

Doesn't mean they are old or discarded or bad.  It just means, life
progresses.   We no longer have a great need for horse-carriage makers in
this society.   That doesn't mean such were not valuable, and those who did
the finest work, might still be for specialty work.  But to reserve
"Transport::Maker"... just for that function...would guarantee a broken
system.



Should software be buggy? Of course not. But life is not
 > perfect, and there are always trade-offs to be made. At this time, I feel
 > that I would be remiss if I didn't also note that David Cantrell is a
 > rather prolific CPAN developer - his work is used by many other
 > libraries, including some that are packaged in Debian.

---

   I don't know him from "Adam" (or Larry?) , so my comments were in NO WAY
personal, and you were able to figure that out (I'm glad I was clear enough
-- sometimes I'm not;  I'm WAY FROM PERFECT.

    I am more than happy to step aside and let more competent, and more
energetic people people run things -- will even help them, to come up to
speed if I can (hopefully they don't need to throw out the baby with the
bathwater and have all new code, BUT, if the new code works as well or
better than the old, can't argue against technical merit.

    Software Engineering has been attractive to a wide range of 'outsiders'
because it was a meritocracy - not based on "established privilege" from
past deeds.  It's has usually been based on 'recent work' and current
knowledge, (at least with smart engineers), as peoples skills change
drastically over time.

But some people -- especially as they grow older, become more indoctrinated
to larger cultural ways of doing things which put meritocracy at the low
end of the scale.  Over the long term, fresh blood needs to make sure that
doesn't happen and older blood needs to be wise and graceful enough to
allow and encourage it!  Otherwise, there will be no future "generations"
of that language.   It will become 'Algol', Simula, Ada...etc.  Still maybe
used in fractional markets, but dead for all intents and purposes.

When the old blood becomes an ***IMPEDIMENT**, to the continued thriving
and long term existence of the language -- their existence in the upper
hierarchy becomes a problem, and at some point,    even if they are
*popular*.

Popularity != good for long term benefit of community (there are world-wide
historical examples of this .. charismatic leadership (maybe be a group,
not just a single person)  leads people / country in down dead-end path
(morally or financially, corrupt/bankrupt or such).  In the worse examples,
wide-scale (including world) damage can be the result, though damage is
usually limited to the sphere in which they operate (I find it 'unlikely,
that mismanagement of perl would result in the same level of harm that
mismanaged government does, for example).


   Therefore, when it gets to a point where it's not just bothering me --
and NOT EVEN the bulk of the existing community necessarily (as it is a
self-selected people who have accepted the status quo; as most of those who
can't leave -- dissension is harshly attacked by the existing status quo
community); and when it starts to affect the viability (survivability) of
the the future of the language/project as a whole because the harm it is
causing turns away too many people (attracts too few people) it causes harm
in attracting sufficient 'new blood' to ensure the product will survive
into the future.    **That's when things get dangerous.***

 >
 > On the other hand, I guess your statements are more generally stated
 > rather than specifically levelled against Mr. Cantrell, ...

----

   Never heard the name before (or if I have, it's not in my active memory
(alot of things are buried, and recallable given sufficient time and the
right stimulus/i).  So utterly without personal bias -- I appreciated his
candor and response.  It more clearly reminded of specifics in this problem
space.


 >
 > Note that most licenses mention that the software is provided "AS IS",
 > without any warranties, express or implied, INCLUDING fitness for a
 > particular purpose. That means that open source software might well not
 > do as advertised. It is the risk you take when you decide to benefit from
 > software that has been provided to the community in the public interest.

---

   Not pertinent to whether or not it deserves a reserved spot on CPAN.

 > TL;DR: I am not aware of any case on CPAN where an author is
 > intentionally, and malevolently, attempting to "sucker" you into paying
 > to make it work.

----

   I am not either...  But I know of some cases, NOT on CPAN where that has
been the case.   If that should arise, or the appearance of that should
arise on CPAN, it would tarnish CPAN as a the free and open repository it
is...

Thanks for your thoughtful comments, I hope I've addressed your concerned
and further clarified the direction I think the perl community (not just
CPAN) should move.

Linda



(of course, by doing so, coming from me, it guarantees opposition against
me, and being on many peoples "doo-doo list"... BUT, unfortunately, for
them, I've noted that once an idea is out there...it seeds and eventually
(sometimes a few years later, sometimes sooner) comes to be almost exactly
what I wrote.  Just the messenger is usually drawn and quartered.

I've already resigned myself that I was Cassandra in a previous life...:-)






nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About