Caleb Cushing has spilled a lot of virtual ink writing about the obligations that come with releasing open source software.
Yes, I think I’ve proven that volunteering to do open source comes with a responsibility or obligation.
(emphasis mine)
I kid you not. That is what he thinks.
And people have responded reasonably. In my opinion.
What is Caleb’s End Goal?
HUH? you people need to READ what I SAID and STOP reading INTO it.
I can think of three possibilities.
- He likes getting comments on his blog (I can’t blame him)
- He want open source authors to do more than they are already doing
- If something is released [on CPAN?] that isn’t up to a certain standard, he would prefer that it wasn’t released.
More Comments
He has started closing commenting on his posts so this can’t be the reason. He could still be deriving satisfaction from high numbers of visitors though.
Open Source Authors do More
This is unrealistic. If we1 wanted to do more, we would be doing it already. If we had the time and the inclination to improve the quality, improve the documentation, fix the bugs…
Basically, someone whining, isn’t going to make people increase the amount of effort they put in which is probably already at the limit of what they want to do.
Don’t Release Imperfect Code
Or when is nothing better than something?
Chromatic mentioned one case in the opposite of modern. When an example is actively bad it reflects badly on Perl. But I think that a programmer who is motivated enough to release code to CPAN will be good enough to not write bad perl.
When a novice writes poor perl examples and others learn from those examples, it reflects poorly on perl. With CPAN, the natural barrier means that a novice is unlikely to be able to upload a module before they become more adept.
Of course, as Dave points out, a lot of what is on CPAN is not exemplary despite the fact that the authors are not novices. However, a certain amount of bad perl is certain to make it onto the internet. Should we exclude all imperfect code and lose perfectly adequate modules?
edit: edited for clarification.
I consider the cases of Authen::SASL, POE and AnyEvent that I’ve relied on recently. Now, in all those cases, the documentation has varied from pretty good to excellent (and they also have handy test cases). However, even if they had no documentation at all, it is surely better to have a working example that you can trace through with the Perl debugger than it is to have to write it yourself from scratch.
In the worst case, if the code is completely unusable I have to write to myself from scratch, but I would have had to do that anyway if the code had not been released. And if I’m not a developer I still wouldn’t have been better off without the code.
So Caleb, consider what you’re asking for. You might think that it would be great if you don’t get perl modules released to CPAN that are a bit rough around the edges, but I assure you that you’re wrong.
1. Yeah, I said we rather than they, even though my own contributions are limited.
“But I think that a programmer who is motivated enough to release code to CPAN will be good enough to not write bad perl.”
I was with you until right there. CPAN is full or horrible Perl code. There’s over 20,000 distributions on CPAN. Do you really think they’re all good Perl?
Yep, something is better than nothing.
I release my open source free software in case someone finds it useful. I don’t know in what ways people might find it useful, that’s their business.
If they look at it, think what I’ve done sucks and as a result of that release some software that doesn’t contain what they consider to be my mistakes, then my software has still been useful, in that they’ve learned what not to do.
Now if I hadn’t released this hypothetical module, because I felt it didn’t pass some criteria of “worthiness” or because I didn’t want to support it, then that person would never have benefited from that “use” of my work, and could well have wasted time discovering the things that I’d already found out.
Of course such a situation is highly unlikely because all software I’ve released is perfect and cannot be improved upon.
@dave -
I may have to edit the post to clarify what I meant here. What I intended, was that CPAN authors are not novice perl programmers. The bad perl they put up will not be novice bad perl, but obfuscated bad perl. (Woolly thinking there Jared) Admittedly I could check this out myself so I’d know for sure.
Thanks for pointing it out.
@Sam – you’re saying you wouldn’t be able to honestly wear this tee-shirt eh?
(actually, I was looking for some slightly different text, but this is close enough)
You, Sir, are an optimist.
Using Perl (or any other language) for quite some time will not make your code any better. Code quality is not a function of time.
I did a little rant today and showed a couple of lines of really bad code. But I wasn’t making fun of a newbie. That code is from a guy who has been working as a Perl developer for at least eight years now. Eight!
Caleb doesn’t seem to be complaining about bad code though, but bad documentation. The issue of it being used as an example for poor code doesn’t really apply to what he has said.
@confuseAcat – as I said on your blog, those few lines of code don’t look that bad. What made you think there was deliberate obfuscation?
@Graham – I know he wasn’t, but I was considering what his end game was (code without documentation not released perhaps) and then trying to think of some reasons I would prefer code not to be released. The simple fact is, that in almost all cases (and particularly for CPAN where there are barriers to novices releasing code) I would prefer to have even bad code to no code.