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 (rt.cpan.org 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.
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?"
Re:Incorrect Premises
Alias on 2007-02-20T23:48:23
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.
Re:Incorrect Premises
chromatic on 2007-02-21T03:53:21
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 support it at all, perhaps toning down your anti-M::B rhetoric in the future could help avoid similar fiascoes.
Re:Incorrect Premises
Alias on 2007-02-21T08:56:46
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 significant part of my problem with Module::Build community is that it behaves like an isolated community imposing new standards that break things, when it could have so easily done the same thing in a way that wouldn't break CPAN.
Re:Incorrect Premises
chromatic on 2007-02-21T18:32:26
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?
Re:Incorrect Premises
Alias on 2007-02-22T01:25:20
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 KRe:Incorrect Premises
chromatic on 2007-02-22T08:37:59
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.
Re:Your svn
Alias on 2007-02-21T00:56:50
SureRe:Your svn
jjore on 2007-02-21T02:27:19
Yay!
