Open Source Library Quality Flamebait
-
There is no obligation to free labour. Every hour you put in working on your project for free is a gift to the world. If the world comes back to you and says “You are a bad person for not supporting this thing I need you to support” then fuck them. If they want that they should pay you for it, or do it themselves.
Filed under: shameless blakeybaiting
-
-
This is why I stay away from MS stuff for my OSS projects, so I don't have to put up with the crap from this sort of people.
[spoiler]bite you rat[/spoiler]
-
-
Filed Under: Beating the dead meme
Addendum: Professional meme generation services only $99.99/mo
-
-
Seems more like @boomzilla-baiting, with that link at the end.
-
Huh...didn't even notice that. But I started reading it and a few paragraphs in I had no clue WTF he was talking about and it showed no promise of actually going anywhere so I gave up. I was a little surprised because the original article linked got to the point much more quickly.
-
I think what he's saying is that if you agree with the premise of that first article, then you agree with feminism.
-
So shitty open source == lesbianism? I can live with that.
-
Gnu is the warmest color
-
Seriously, this article isn't bad at all. He has two main points:
- High quality software takes time and effort. Time is money. OSS is not likely to produce much of it. Thus, most OSS sucks.
I would just add that quality software takes time and effort. And bureaucratized corporate environment might ensure the first part, but isn't likely to inspire much of the later. Which is why a lot of paid software sucks as well.
I guess the only good software comes from those happy occasions when you have highly motivated, competent people working on their passion project AND getting paid for it.
- If you do produce some crappy OSS, you shouldn't feel bad it's crappy.
Ok, fair enough. Not every project on github deserves to be treated as a fully packaged battle-proven product, ready for consumption. Sometimes you just want to share some code, showcase it to others, maybe see if someone else is interested in chipping in, or just giving them an idea where your skill level is and how things can be done, whatever. And having something is usually better than having nothing.
A simple one line in README.md, telling potential consumers what to expect ("just for fun", "using it in my production", "full stable version", blah blah) should be good enough protection against consumers getting burned.
-
A simple one line in README.md, telling potential consumers what to expect ("just for fun", "using it in my production", "full stable version", blah blah) should be good enough protection against consumers getting burned.
What about consumers who feel that they shouldn't have to read documentation?
-