Top reasons why we won't use your Perl CPAN distribution(showmetheco.de) |
Top reasons why we won't use your Perl CPAN distribution(showmetheco.de) |
> Why did you even upload it on CPAN if you don't even
> care if anybody is going to use it?
Possibly out of self-interested generosity. They hope that others will benefit from it, they hope that they will receive bug-fixes, and they hope that it will be used as a starting point for something better. And they hope that by setting an example of releasing code, that they in turn might gain access to that "something better".I think you've provided excellent reasons to prefer one module over another if there are alternatives, but I'm not sure why they are directed at the hypothetical author rather than the potential user. Let's flip it around: why should the author care if you use his code? Is it better that the unmaintained code remain unreleased, or is it better to have it out there?
I don't see why the author would care if you use it unless you are capable of contributing to it in some way. And I'd argue it's better to have it out there than unpublished, but that CPAN could do a better job of distinguishing between active and inactive code in the case that there are better alternatives available.
But what I meant by 'author should care if somebody uses it' is that he should make it usable and understandable for somebody else. If it's not, what the point of making it public and open source?
Maybe someone will get some value of it. I don't want it, I don't care to put effort in, but hey, if someone else does: cool!
Basically, putting stuff out there is not that different from the freecycle mentality.
The place you seem to come from is that "Oh they want to make an open source project, that means they must want to be $0 vendor for my company!". Honestly, I hate that mentality. Instead of coming in and demanding I give you more effort for free, take or leave the free work I choose to do and let it be. That's not to say I am not open to suggestions or maybe even explaining or fixing things, but you have no right to expect it of me.
What makes this worse is that your "rotting" should be written without quotes. Most code rots incredibly fast, even if it is written to high standards. Your makefile may break, your dependencies may see an interface change, popular architectures may change (an .ini file for preferences?), etc.
- for what platform(s) it is written (e.g. C code where tagged as 'Unix', that use Linux-isms)
- what the license is (home page claims 'free' or 'open source', source files mention license A, read me mentions license B)
- what the library does and, almost more importantly, what it's limitations are.
- what the dependencies of the library are.
- what systems the code has run on (it can for instance be useful to know that code has run in big-endian machines if your machine is big-endian)
The more of this info is present, the higher the probability that I will try to use your software.
There is lots of code out there where too little of this metadata is present. If such software is not solving some unique problem, I would prefer it if its writer did not make it available.
I do agree that I don't have any right to expect anything from the open source software, I am just saying why I won't use some of it.
I have a couple of large 80% done libraries I wrote to publish as open source -- which I am going to rewrite heavily before I'm letting anyone see.
(Answer to next question: Yes, a couple -- instead of finishing one and starting a second. There are reasons in addition to me being stupid. :-) )
At least I learned a lot.
Edit: About the article -- it is hard to create a good API, I've designed lots of APIs in my days -- and I don't think I've done a single good one. :-(
Good API++