Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Tuesday February 20, 2007
12:27 PM

Continuity or Death

[ #32451 ]

This could so easily be a rant.

But I present to you the following, and I'll try to restrain myself from pointing fingers.

When you look at code over a long period of time, you can see any given package as either healthy, sick, or dead.

Healthy code has a tested and stable implementation, with few to no CPAN Testers FAIL entries (N/A are permitted). Over time, it will replicate (in a fashion) by becoming dependencies for other packages.

Sick code tends to have weird bugs ( entries) that hang around for a long time. Very sick code fails on entire platforms for long periods of time (bad CPAN Testers results) despite claiming support for it.

A variation of this is necrotic code, that can't change for legacy reasons but is terminally sick. In the best cases there is a better replacement and we can just cut out the code that uses it and replace it with the newer code.

A good example of this is something like IO::Scalar which can't change its behaviour for legacy reasons, but is generally replaced by IO::String.

Sometimes packages die from a more conceptual point of view, because they are implemented based on an incorrect premise. You tend to be able to recognise these from CPAN Ratings, where the pattern of ratings starts out positive but gets worse over time as the second and third-order effect of the incorrect premise takes hold.

You also tend to see people adopting it enthusiastically, and then later abandoning it with equal enthusiasm (as we've seen for things like prototype.js).

These can often be fixed, if often reluctantly (*cough* Module::Build and PREFIX *cough*) :)

The one common factor leading to the death of packages, and indeed entire projects, appears to be continuity.

That is, does the project keep going, and is there sufficient hours of work being put into the project to keep it alive, growing, or removing bitrot, or correcting conceptual mistakes, and so on.

Because if you don't ensure continuity, and ensure it in advance, you're only one step away from all your work being completely pointless.

This is particularly important in Open Source projects, because Open Source projects aren't typically income-generating. The state in which someone is working on an Open Source project without being paid is quite rare.

So it's unbelievably important that authors of Open Source projects harvest those moments in which someone is willing to work for you for free. Things like co-maint permissions and version control access and being willing to give up some amount of creative control once you can't work on a module as much as you'd like to.

Or all your work will ultimately be for nothing.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Sometimes packages die from a more conceptual point of view, because they are implemented based on an incorrect premise... These can often be fixed, if often reluctantly (*cough* Module::Build and PREFIX *cough*) :)

    "Incorrect premise" is about the nicest thing anyone can say about PREFIX. If you were going for accuracy, you might have said "Why would anyone have ever thought this could possibly work correctly?"

    • I think the problem with Module::Build and PREFIX was two-fold though.

      Firstly, PREFIX was implemented on a completely incorrect premise.

      But the secondary problem was the believe by Module::Build that they could utterly break compatibility with PREFIX and then document their way past it because they were right.
      • You say that as if you believed that it were possible to be compatible with PREFIX. Given that even Schwern believes that the feature just plain doesn't work, how in the world would the M::B developers ever satisfy you? If they made it do what everyone seems to think it does, they've broken compatibility with it. If they somehow magically made it do what it actually does, they get complaints that it doesn't work the way everyone thinks it does.

        If you're suggesting that the only sane approach was not to

        • I'm suggesting that the toolchain is a single entity.

          You can't just invent entirely new standards and make half a dependency chain act differently to the other half of the toolchain. It breaks the entire

          So either Module::Build [] should be bug-compatible with the way that PREFIX works, or the Module::Build people should have worked with the rest of the toolchain to deprecate the entire feature across the entire thing, while leading a suitable replacement that required no increase in work from the user.

          A signif
          • All this while I thought the important half of the phrase "backwards compatibility" was "compatibility".

            If the "whole toolchain" really is a single entity, then we ought to consider MakeMaker severely broken on platforms that don't include a working make utility. Should M::B not work on those platforms, for the sake of backwards?

            • Backwards is entirely orthogonal to compatibility.

              I just find it a shame that in trying to not be backwards, the initial choice was to also not be compatible.

              Adam K
              • I really can't see how it's possible to be compatible with a feature as broken as PREFIX. If you support it as it worked in EU::MM, then you surprise everyone who expects it to do something sane instead of spewing files randomly over the filesystem. If you make it work so that it does something sane, it doesn't work the same way that EU::MM does.

                Please enlighten me.

  • Just to expand on my previous comment...if a person is the author/maintainer/whatever of an open source project, there are ways to learn a little bit about folks who offer to help with your project. One could look at posts to sites with content related to your project(Perlmonks, for example), anything that they've posted to Sourceforge, bug reporting sites, and mailing lists. So you can see what your prospective volunteer has done, which could alleviate concerns about giving up a little bit of the creati
  • I appreciate your perspective, as well as the restrained delivery.
  • I've found that it's a pain to find mentions of the URL your SVN repository is at. It's nice once I've gone to the work of 15 minutes googling to get the URL but prior to that, it's painful. Mind fixing that? A pointer on might be nice.