Hacker News Reader

Comment by bachmeier | Hacker News Reader

I've made the point repeatedly over the years that open source projects have to sell something if they want financial support. In the case of Perl, maybe it's a particular implementation that comes with printed documentation. "Download the stuff you want to use and then make a donation of arbitrary size if you feel like it" isn't going to work. The RHEL model won't work for most projects, because Red Hat has traditionally sold support services. Slackware would be a better example. You used to be able to buy CDs with the new release if you wanted to support the project.

View on HN

One of the key things RedHat sells is "your code doesn't need to change for X years" - but a side effect of this is you suddenly have a BUNCH of changes that need to be made every X years as new distributions come out.

Even though Microsoft deprecates versions of Windows, they often keep supporting the APIs used for insanely long periods of time. Open Source software doesn't really have the incentive to do this unless "forced" by leadership or a standards body (and even that isn't entirely well enforced, how deviated from Posix are we now).

Java may be similar to a cross between these - as old versions of the JDK continue to be supported and developed, but I assume there's money flowing somewhere to do so.

I think that's true but it's hard to do: I can't go to purchasing and say “we should donate $50,000 on these 139 projects”, and it will definitely raise questions if you're paying for something vague or not clearly linked to a business value but selling support puts the project in the critical path for actually having to deliver it.

I work on a number of projects but they're all relatively small so even if the money was coming in it wouldn't be enough to hire someone / quit my job and that means that you're in a dynamic where what'd help most is contributing developer time but that's a lot harder than making a purchase for most organizations. If I offered paid support (or sold books or trinkets) it'd almost certainly bring in 1-2 orders of magnitude less than it'd need to transform the project structure.

> I can't go to purchasing and say “we should donate $50,000 on these 139 projects”, and it will definitely raise questions if you're paying for something vague or not clearly linked to a business value but selling support puts the project in the critical path for actually having to deliver it.

That's basically the point I'm making. Paying $75 for printed documentation is easy to justify if your job involves Perl. If four developers work on Perl code, that's $300, which is nothing to the company and a lot better than the $0 they're getting now. Another example would be prioritizing bug fixes and new features.

The problem I’ve seen is that it often goes more like “do we really need 4 copies, can’t they share?”, “isn’t the 2020 version still enough for 2021?”, or “isn’t that all online anyway?”, and even if it works $300 after overhead isn’t much developer time. Trying to do it sideways like this can be frustrating at large companies because the same place which will pay an enterprise vendor 7 figures to have the privilege of training the vendor’s support contractors will nickel and dime you for less familiar arrangements.

The bigger problem to me is that maybe I could do that for Perl but it’d be even harder to say I need printed docs for every single CPAN module used on a project. Maybe if the core Perl team gets a ton of support they can spread some around but that’s tricky to match to the projects most in need.

There's always ActiveState Perl: https://www.activestate.com/products/perl/

The last active state perl maintainer was fired years ago.

That would make it inActiveState Perl...

This is untrue.

Reply on news.ycombinator.com