The end of an era: Saying goodbye to search.cpan.org

I think I understand what you're trying to say, but I'm not sure that description makes any sense. Prior to the popular OSS version being created, in most cases an OSS version didn't exist so there couldn't be a large set of users of OSS.

Apache has been run on windows for decades (or very close to it) now. Same with Sendmail, and MySQL These are people that chose to run open source software on a proprietary operating system (windows 98 or windows 2000), so I'm not sure large sets of OSS users had much to do with it. I think it's more that the software was robust, it worked, and it was free.

I think what your point is getting close to though is that it's probably true for software that has a more technical audience. Setting up server software requires some technical fluency, even today (if much less than in prior decades), and those people are more likely to both have heard of competitors, to be able to assess how they might perform in comparison, and to be able to actually install and troubleshoot them given the generally more complex documentation.

What I think we've seen over the last few decades though is that those technically minded people have come to become users of OSS. That is, I think your cause and effect was backwards, as those people are now users of OSS because there's good, solid OSS software that makes sense for them to choose, and once they're using it they are OSS users.

The basic idea is simple though. Use strict. Use warnings. Use new features and best practices modules (Task::Kensho[2] an help here) when them make sense (e.g. Moose/Moo). Be aware at least what PBP[3] is, and if you feel so inclined, use Perl::Tidy and/or Perl::Critic (even if your own defined subset of rules) to give yourself an idea of what is considered good practices (and when to throw them our for that elegant line or two, just don't forget to comment it so you don't confuse yourself when you see it months/years later). Basically, if you care about the code you write, you should find yourself gravitating towards writing Modern Perl anyway, and the speed at which it happens is largely determined by your exposure to the Perl community at large.

My own personal set of best practices means almost always using something like Function::Parameters or Kavorka, and possibly Moops.[4]

1: https://metacpan.org/pod/Modern::Perl

2: https://metacpan.org/pod/Task::Kensho

3: http://shop.oreilly.com/product/9780596001735.do

4: https://news.ycombinator.com/item?id=11633961

Illustrated guts is the description of the perl5 internals, in html and images. Metacpan still does not allow displaying it and I won't pay for hosting services.

Static GitHub pages maybe, but how stable will that be, and it's another link away from the primary content. They knew of this problem for years.

Uhm, I can't see Catalyst listed in the web development section... Has it fallen out of grace ?