If a person appears, offering me a solution to get me to my destination, leads me down their ally, taking my time and attention and meaning I lose the opportunity to check other solutions, and at the end of the ally I fall into a muddy riverbank and see a sign saying 'TODO: build bridge', we wouldn't call that a gift, we'd call it deceitful and cruel (or worse).
You don't owe me your work, but I don't owe you gratitude for it either. It's not a gift, it's not even that transactional. (Although that's no excuse for being nasty or threatening!)
With an open source project, it's unlikely that a person will appear and offer you anything and lead you down any alley. If you're trying to cross a river and come by a raft and start whining about the lack of a bridge, let alone saying that someone wasted your time, you're ungrateful.
"TODO: build bridge" means that the author thought that it's a good idea to build a bridge, however the author has other priorities and has postponed the bridge building to the time that it's actually needed (perhaps by someone else). Now you stumble by in need of a bridge, what should you do? Build the damn bridge, of course.
You're not owing any gratitude to anyone, but badmouthing someone for not doing exactly what you want is plain bad behavior.
There's a difference between finding a raft (here's some source on github which takes a few minutes to look at) and being enticed by a bridge (here's a homepage showing up in search results, presenting a packaged solution as an answer to the problem I'm having, which doesn't turn out to be a problem until hours or days of integration work).
When you're doing commercial product development, don't use "gifts". The FOSS tool/product may be very nice, very thorough, and all kinds of other wonderous "and it's free too!" adjectives; remember that it is, as the article says, a "gift": its creator and maintainer is under no obligation to ensure your needs are met. It may overall be a tremendous tour-de-force, but remember there is one key difference between FOSS and commercial software: there are small, ugly, uninteresting BUT IMPORTANT parts which NOBODY wants to do short of a serious paycheck. When your product comes to rely on those parts, will fixing problems prompt a "ok, I'll put 3 engineers on overtime to get it done" or "I'm at the beach; be happy with what you've got - it's a gift, remember?"
Yes, but have you had any commercial vendor say "Ok, I'll put 3 engineers on it"? Unless there are 100 other customers with the same problem you have, your bug report will be put on the list that they'll eventually get to in a month or 6.
For commercial products, your only option is to threaten to pull your business. Since it would probably cost thousands or tens of thousands to fix your problem, unless you are a big customer or the problem affects a lot of other customers, your problem will not be a priority.
For open source, you have the following options:
- ask the author to fix it. This works surprisingly well, if you're polite.
- post a question to the projects mailing list, and you will usually receive a response
- fix it yourself
- pay somebody to fix it
- pay the original author to fix it
Notice that there is ALWAYS a potential solution. Sometimes it's expensive, but for commercial software, too often you are SOL.
He didn't "appear". You came across a guy lashing together a raft, for his own use, demanded a bridge, and then became irate that he didn't pull apart his raft and make you one right then and there.
Worse still, the poor guy offered to let you use his raft if you wanted to. Its not his fault you were moving elephants.
Not quite. He listed his raft-building skills on the internet, told you where the raft-building party was, all in an environment where folks make good money on raft consulting.
Then the guy says "I don't do the hard part, go away"
Comments
If a person appears, offering me a solution to get me to my destination, leads me down their ally, taking my time and attention and meaning I lose the opportunity to check other solutions, and at the end of the ally I fall into a muddy riverbank and see a sign saying 'TODO: build bridge', we wouldn't call that a gift, we'd call it deceitful and cruel (or worse).
You don't owe me your work, but I don't owe you gratitude for it either. It's not a gift, it's not even that transactional. (Although that's no excuse for being nasty or threatening!)
With an open source project, it's unlikely that a person will appear and offer you anything and lead you down any alley. If you're trying to cross a river and come by a raft and start whining about the lack of a bridge, let alone saying that someone wasted your time, you're ungrateful.
"TODO: build bridge" means that the author thought that it's a good idea to build a bridge, however the author has other priorities and has postponed the bridge building to the time that it's actually needed (perhaps by someone else). Now you stumble by in need of a bridge, what should you do? Build the damn bridge, of course.
You're not owing any gratitude to anyone, but badmouthing someone for not doing exactly what you want is plain bad behavior.
There's a difference between finding a raft (here's some source on github which takes a few minutes to look at) and being enticed by a bridge (here's a homepage showing up in search results, presenting a packaged solution as an answer to the problem I'm having, which doesn't turn out to be a problem until hours or days of integration work).
...which is a variant on my take of the article:
When you're doing commercial product development, don't use "gifts". The FOSS tool/product may be very nice, very thorough, and all kinds of other wonderous "and it's free too!" adjectives; remember that it is, as the article says, a "gift": its creator and maintainer is under no obligation to ensure your needs are met. It may overall be a tremendous tour-de-force, but remember there is one key difference between FOSS and commercial software: there are small, ugly, uninteresting BUT IMPORTANT parts which NOBODY wants to do short of a serious paycheck. When your product comes to rely on those parts, will fixing problems prompt a "ok, I'll put 3 engineers on overtime to get it done" or "I'm at the beach; be happy with what you've got - it's a gift, remember?"
Yes, but have you had any commercial vendor say "Ok, I'll put 3 engineers on it"? Unless there are 100 other customers with the same problem you have, your bug report will be put on the list that they'll eventually get to in a month or 6.
For commercial products, your only option is to threaten to pull your business. Since it would probably cost thousands or tens of thousands to fix your problem, unless you are a big customer or the problem affects a lot of other customers, your problem will not be a priority.
For open source, you have the following options:
- ask the author to fix it. This works surprisingly well, if you're polite. - post a question to the projects mailing list, and you will usually receive a response - fix it yourself - pay somebody to fix it - pay the original author to fix it
Notice that there is ALWAYS a potential solution. Sometimes it's expensive, but for commercial software, too often you are SOL.
He didn't "appear". You came across a guy lashing together a raft, for his own use, demanded a bridge, and then became irate that he didn't pull apart his raft and make you one right then and there.
Worse still, the poor guy offered to let you use his raft if you wanted to. Its not his fault you were moving elephants.
Not quite. He listed his raft-building skills on the internet, told you where the raft-building party was, all in an environment where folks make good money on raft consulting.
Then the guy says "I don't do the hard part, go away"