Jim,
Jim Schueler wrote:
With regards to Apache::DBI, it is very much supported :)
No. It is not. What little I know of you, you seem knowledgable and
experienced. But you don't seem to have read this thread. The
documentation says that the module will be supported by this list, and
the facts now demonstrate otherwise.
I employ and pay perl programmers. I even initially give a job to young people who are
not perl programmers and initially consider perl as something slightly disreputable -
because that's what they generally learn in school - and make the effort to "convert" them
to perl.
I also have the greatest respect and appreciation for people who create interesting perl
modules, and who then go the extra mile to make these modules available to others on CPAN.
And I will admit to being in that respect merely a "user", and to never have gone that
same extra mile with modules which my employees or myself developed in-house.
When I consequently find and use a CPAN module, and occasionally find a problem with it,
and occasionally find out that despite what the documentation says, it appears that it is
unsupported, I do not however jump through the roof, as you seem to be doing in this case.
You are right, it is not entirely correct that the documentation of a CPAN module would
state that it is supported, when in reality it may turn out that it is not so.
But what is to do about it, really ?
Say that in 5 years, someone downloads Google::Oauth, has a problem with it, looks at the
"See Also" and the "Author", tries to contact this guy, and finds out that nobody
responds. What should happen then ? There are a million possible reasons why the person
who maybe usually responds to such enquiries on this list, may be temporarily or
definitely unavailable these days. Should someone hire a booty hunter to track him down
and force him to answer, or to rectify the documentation or else ?
Nobody is really being paid to spend time scanning the CPAN module documentation, to find
out if there is really someone supporting that module, and updating the documentation to
say "unsupported, use at your own risk".
Can you think of a practical solution to that, for 118,000 modules and counting
?
Several contributors have responded now. To paraphrase, they will (and
I will and so will others) help the best they can. But that's not what
the documentation says. I guess I'm just one of those whiners who
expects the documentation to be reliable.
I use CPAN all the time, I have done so for many years, and I never paid a cent for it. I
download modules, and I incorporate them into applications which I sell for a living. I
have occasionally sent my thanks to a CPAN module developer, but I have never paid them a
commission when I sold their module as part of my applications.
On the other hand, I also do not /expect/ to get something for nothing.
So when I find out that some module is unsupported, while the documentation says that it
is, I accept that. I then try to get help somewhere else, or figure out by myself if I
can understand the source and correct the problem myself. If I can, I will generally try
to send some email to the person mentioned as the author or the maintainer anyway. Most
of the times when I have done that, I haven't got an acknowledgement either. Again, I
accept that, since I didn't pay for the thing in the first place.
Are your expectations different ?
I followed this thread from the beginning. I compared the original
observations with the documentation. And either the documentation is
wrong or (more likely) incomplete. I think it's reasonable to assume
that if no one steps up to take ownership, there is no owner. And hence
the code is unsupported.
Agreed.
Early on, I tried to clarify. Which I'll repeat:
If the code has no significant user base and no identifiable
owner/maintainer, use at your own risk. Pretty much what you say
below.
Agreed.
If the code has a significant user base but no identifiable owner,
there's a lot less risk because you can get support from other users.
Agreed.
Modules with reliable owners, such as Soap::Lite, deserve the highest
level of confidence.
Agreed.
Apache::DBI has no owner and therefore falls in category #2. Or maybe
someone will step foward, and thus category #3. Otherwise, your
comments below say the same thing. Yet for some reason, you turned the
big platitude guns on me.
By omission, there seems to be consensus on these guidelines. All the
quibbling revolves around my estimate that most modules fall in the
first category. Personally, I would prefer no one estimated that 97.5%
(or 118,000 perl modules) are still actively supported by their authors/
designated successors. Because I think that claim strains credibility.
If by this you refer to my previous relation of my own experience, I wasn't trying to
express some general statistic, and i never claimed that 97.5% of modules are actively
supported.
The only things which I stated was that in my own limited experience,
- 90% of the modules which I ever downloaded and used worked as I expected and /did not
need any support/ (for me). In that case, whether they are actually "actively supported"
or not is effectively irrelevant, and I never even tried to check if they were supported.
- of the remainder 10% (which did not work as expected and for which I seeked support),
3/4 of them seemed to be effectively supported, since I did get help. Whether that was
help from the person mentioned as the author or maintainer or not, I honestly couldn't
tell anymore; but I did get help in resolving my problem, and to me this counts as
"supported". In the last few months, I remember that we needed help once, for the
SOAP::WSDL module, and we did get immediate and effective help from the author. But of
course this is purely anecdotical and not a base for real statistics.
- and only 1/4 (thus 2.5% of the total number of modules that we tried to use) seemed to
be indeed unsupported, and either we fixed the issue ourselves or switched to an
alternative module on CPAN - for which in our case there always seemed to be one when we
really needed it.
That does not contradict your classification above. But it presents the same data in
another way, from the perspective of a potential user of CPAN modules.
Instead of classifying most modules as "unsupported, use at your own risks" - which sounds
rather sceptical if not bad - I would say "90% of CPAN modules work just fine as
downloaded, don't worry" which sounds a lot better and in my view also reflects the
practical reality better (mine, anyway).
...this comes with the general open source software caveat - "Using open
source software doesn't mean someone will do *your work* for free".
I didn't originate the thread, but this response offends me. If someone
observes a problem with a module, is the point to discredit them instead?
No, but did anyone really try to do that ?
When I re-read the posts in this thread, I do not really see that.
It seems to me instead that you were the one to turn on the big guns of dismal
disappointment, when maybe there wasn't a real reason to react that way.
You took the case of one issue with one CPAN module, and seemed to turn it into a general
comment about all CPAN modules, and you seem to imply that most CPAN modules are
unsupported - although the documentation says otherwise - and that this automatically
translates to a general quality issue of these CPAN modules. I believe that this apparent
generalisation was what some people here mostly reacted to.
So far, there seems to be a tendency to overlook the substance of the
discussion and react defensively to outsiders (as though I haven't
participated here for 14 or 15 years). What's up with that?
Thanks for letting me get that off my chest.
Welcome :).
-Jim
On Fri, 31 May 2013, Fred Moyer wrote:
In their absence, I'd note that your post has an interesting
ambiguity: Is
the number of unsupported modules 2.5% or 25%?
The 'supported' metric doesn't really translate the same in reference
to open source software as it does to commercial software. When a
commercial software product becomes unsupported (think IE6), then you
are out in the cold. You don't have the source code, so you can't fix
an issue with it, or hire someone to fix the issue. Unless you are
really good with a hex code editor and patching binary files, you're
out of luck.
With open source software like Perl, you may see statements like 'Perl
5.6 is no longer officially supported'. This means you probably won't
be able to get the P5P team to fix bugs or security issues if they
come up. Still, you have the source code, so you can fix it yourself.
CPAN is a bit more murky in that individual authors can decide to
deprecate modules, or they can drop off the face of the earth, but
widely used modules such as Apache::DBI, SOAP::Lite (maintenance
recently stewarded by yours truly) will almost always have volunteers
step up and maintain them, because those volunteers need those modules
to be functioning for own work. In terms of a supported metric, I'd
say modules that are used by more than a few people are supported
100%.
With regards to Apache::DBI, it is very much supported :) But this
comes with the general open source software caveat - "Using open
source software doesn't mean someone will do *your work* for free". If
there's a feature that appeals to more than a couple users, or a bug
that affects more than a couple users, odds are that it will get
fixed. Features that only one user is after will likely not be
implemented by the maintainers, but patches for those features are
usually readily accepted.
On Fri, May 31, 2013 at 10:30 AM, Jim Schueler
<jschue...@eloquency.com> wrote:
No apology please. In terms of trying to qualify any of this, a larger
statistical pool is better. And I am no authority. My perceptions are
largely based on forum postings which causes an inherent bias.
I'd love to see this conversation continue, especially if participants
included those who commit significant resources to their technology
decisions. In other words, people who hire and pay Perl programmers.
They're likely to be as skeptical as I am. I've never been a
cheerleader.
In their absence, I'd note that your post has an interesting
ambiguity: Is
the number of unsupported modules 2.5% or 25%? (For more rhetorical
nit-picking, you probably don't use the ones that don't work :)
Also, the
significant question seems to be whether Apache::DBI is supported or
not.
From Mr. Zheng's point-of-view (in this case, the one that matters) the
number might be much higher.
-Jim
On Fri, 31 May 2013, André Warnier wrote:
Just butting in, apologies.
It may not have been Jim's intention below, but I get the impression
that
his comments on CPAN are a bit harsh.
It is true that a number of modules are apparently no longer
supported. I
have used many modules over the years, and sometimes have had
problems with
some of them (mostly not though). And when for these problematic
cases, I
have tried to get help, the results have beem mixed; but the mix for
me has
been rather good. I would say that in my case, 90% of the CPAN
modules I
ever used worked out of the box. For the 10% remaining, in 75% of
the cases
I did get help from the person advertised as the author or the
maintainer,
and in 25% of cases I never got a response.
But then, as Jim himself indicated, people move on, without necessarily
changing their email addresses. Considering how old some of these
modules
are, I guess people also retire, or even pass away.
But the fact of the matter is that CPAN is still an incredible
resource,
unequalled in my view by any other similar module library of any other
language anywhere. And I find it amazing that at least 90% of the
modules
which I have downloaded from CPAN and used over the last 15 years, just
work, and moreover keep on working through many, many iterations of
programs
and perl versions, and that in fact one very rarely needs additional
support
for them. When I compare this with other programming languages and
support
libraries, I believe we perl programmers are incredibly spoiled.
Another area where CPAN shines, is the documentation of most
modules. I
cannot count the times where I was faced with a request in an area
of which
I knew nothing at all, and have just browsed CPAN for modules
related to
that area, just to read their documentation and get at least an idea
of what
this was all about.
In recent years, Wikipedia may slowly becoming a runner-up, in terms of
general information. But when it comes down to the nitty-gritty of
interfacing with whatever API (or lack of ditto) programmers in
their most
delirious moments might have come up with, these CPAN modules are
unbeatable. Even if after that you decide to program your stuff in
another
language than perl, it's still useful.
(Just for fun, go into CPAN and search for "NATO" (or more
pragmatically,
for "sharepoint" e.g.)(or even, God forbid, for "Google" or
"Facebook" ;-));
who thinks of such things ?)
So, to summarise : that some modules on CPAN would be marked as
"maintained" or "supported" and would turn out on closer inspection
not to
really be anymore, I find this a very small price to pay for the
wealth of
good information and working code that lives there.
My sincerest thanks to CPAN and all its contributors and maintainers
over
the years (that includes you of course, Jim). What you have done
and are
doing is of incredible benefit to many, many programmers worldwide.
André
Jim Schueler wrote:
I still use Alpine. And they never fixed the bug where ctrl-c (to
cancel
a message) and ctrl-x (to send) are so easily confused. Oops.
Maybe it's
time to start using a mouse.
Having wasted so much time, I'll try to be succinct:
Most modules on CPAN are bascially throwaways and not supported
at all.
Use them at your own risk.
There are some modules that are just obsolete. Good intentions
aside,
the developers lost interest and moved on. These are less risky if
there's an established user base.
There are some very good modules, widely used, that are fully
supported
and perfectly safe for a production environment.
Most mod_perl modules, especially the core modules, fall into that
last,
gold standard, category. In many cases, support is transferred
from one
individual to another. And so that commitment is documented. But
if a
module is no longer supported, don't lie about it. Support forums
are an
incredible resource. But if commercial software developers similarly
blurred this distinction, every p.o.s. would be advertising free
24x7 tech
support.
Apache::DBI seems like a #2 pretending to be a #3. On the basis of
your
response, I've concluded that Apache::DBI is no longer supported
and has
been superceded by newer modules. Especially if no one responds and
explicitly accepts the responsibility, this seems like the most
appropriate
answer for the poster of the original thread.
I owe you a :) from a couple posts ago. :)
-Jim
On Fri, 31 May 2013, Perrin Harkins wrote:
Hi Jim,
I appreciate the thought, but I'm not the mod_perl list. If you
look at
who
has done the most support around here recently, it's probably
Torsten.
(Thanks Torsten!) More to the point, there are many people on
the list
who
know enough perl to help with a question about Apache::DBI. It's a
common
practice to point people here for support on mod_perl modules.
What are you getting at? Is there a module that you're having
trouble
with
and can't get support for?
- Perrin
On Fri, May 31, 2013 at 10:56 AM, Jim Schueler
<jschue...@eloquency.com>
wrote:
There's an existing thread with an Apache::DBI question. But
since I want to post a separate question to this list, I
decided
to start a new thread.
Just got done reading the Man page for Apache::DBI. One of the
last notes suggests that this package is obsolete (having been
replaced by Class::DBI or DBIx::CLASS). Beyond that is the
following:
Edmund Mergl was the original author of Apache::DBI. It is
now
supported
and maintained by the modperl mailinglist, see the mod_perl
documentation
for instructions on how to subscribe.
Unless Perrin Harkins agreed to take over support for this
module, then that statement is not true. Otherwise, out of
respect for Perrin, I'll try to be general.
(Aside: Am I the only developer that comes across 'unless
() {}
else {}' constructions?)
It seems very few distros on CPAN are actually supported. For
my part, I still monitor this list to support my own
contributions from *many* years ago. And I k