Even if a person is frustrated or doesn't communicate well, he or she is still telling me about a problem. As a developer, I find this much better than not knowing about the issue at all. How many people receive thousands of E-mails for their thousands of downloads? Feedback is rare.
Usually, frustration is rooted elsewhere. The person has something to do, and is annoyed that it (still) can't be done, probably after trying my project along with a number of others. I try not to take this personally.
So my first response is to be civil. I don't even talk about anything mean they might have said, I focus entirely on the problem. I solve that problem, and say "here you are".
The response to this has always been gratitude, and even amazement that I solved the problem. It seems that once the person reaches the point of yelling at a developer, that person has given up and doesn't really expect anything anymore.
When you receive bug reports, keep in mind that bug reports are crucial for your work. If you don't know about problems, you cannot fix them. So always thank each person who sends a bug report.
...
By all means help individual users when you feel like it, if you feel you have the time available. But be careful to limit the amount of time you spend doing this-- don't let it eat away the time you need to maintain the program! Know how to say no; when you are pressed for time, just "thanks for the bug report -- I will fix it" is enough response.
I like receiving bug reports. I like even more those cases where people say "the problem is in this bit of code". The thing that put me off doing my open source project is that some people don't have the chops to sys admin their own boxes, and try to get free help from me. They try to make out it's my code of course: "I can't get the database to load into MySQL. Can you fix it?" "It's saying something about 'can't load module nnn'. Is it broken?" I try to be civil but after three or four iterations ("OK, it loads but now I get some error in the logs about 'Can't connect to database'. I wonder what that could be?") well, life's too short and I have actual systems to run, actual bills to pay.
So although your counterpoint is good I would nonetheless say the author is spot on, and there are an awful lot of rude bastards out there who don't deserve free code, let alone free support.
I usually ignore "help request" email or "feature request" one because basically, to reply these emails occupies a lot of time. But "bug fix" email are pretty useful. I do write test cases for code, but a lot bugs are about platform specification, compiler differences which is hard to be found by your own.
um... no, not really. There is proprietary (you mean proprietary, not commercial) software without any kind of support provided to the user and there is open source software with _commercial_ support.
No, I'm speaking to those who are worried about their commercial software not being able to compete with 'free' alternatives.
That '_commerical_' support you're referring to doesn't scale worth a damn, so it's easy to out-compete those folks as a business and provide a superior product.
"That '_commerical_' support you're referring to doesn't scale worth a damn"
Please elaborate on this comment. Redhat has basically been the poster child for the free software/commercial support business model for over a decade now. I believe support for an open source software product can be scaled as a business.
Joel Spolsky summed it up pretty well in his last Inc. article:
"...The Web consulting business was great, but it had one problem: limited margins. You could charge only so much for an hour of some consultant's time -- in those days, maybe $200. Some of that went to overhead (say $20) and some to pay the consultant's salary (maybe $70). That leaves you with a mere $110 per hour in gross profit. That's a lot of money, but it paled in comparison with margins in the software industry, in which you can produce additional copies of an application at virtually no cost."
So, if a body-shopping service company is competing against another body-shopping service company, they're facing the same per-employee costs and will have no problems in their market. However, if a body-shopping service company is competing against commercial software for the exact same product and market, commercial software will face lower costs and receive higher revenue for the same work and so will have more resources to bury that competing body-shop every time.
Also, if our company receives a service call, we regard it as a failure of our product to address our customer's needs. If a 'commercial' open source company receives that same call, they regard it as money earned from a support ticket.
Given that difference, which software product would you prefer to run in your business?
Also, if our company receives a service call, we regard it as a failure of our product to address our customer's needs. If a 'commercial' open source company receives that same call, they regard it as money earned from a support ticket.
Given that difference, which software product would you prefer to run in your business?
Since you and the followup are both wondering why you're being downvoted, I thought I would call this out, and point out that this part of your comment is why you're being downvoted. Because you're assuming that the Open Source support business model is to build shoddy software in order to get more support calls. This is FUD that is frequently used by proprietary vendors to try to discredit Open Source solutions. Open Source developers rightly take offense to being told they are not only building crap, but that they are doing it in order to fleece customers out of their money.
Proprietary software does not have a monopoly on quality software, and never has.
Not sure why you downvoted, I thought you made some great points. However, your example helps illustrate what I've been saying.
Say you want a car. You may want to go to the dealership and just buy one (Toyota's automated process, thus lowering marginal cost). However, maybe you're the hotrod type and would rather build it and customize it yourself. You pay for someone to help you build it and troubleshoot any mistakes you make along the way. Sure, it took longer to build, and was probably more expensive, but it's exactly want you wanted. I think that's where the value of opensource/support lies.
Commercial open source companies (at least Redhat) use subscription models for their support (in addition to consulting, professional QA, etc) so I don't think they would consider troubleshooting software money earned. In fact, I think this gives them a greater incentive to maintain the quality of their software so they get less support tickets and scale to have more subscription fees per support person. I guess you can say that RedHat, through their support, sells the peace of mind of having that support person if you want to go the open source route.
I've no idea why I'm receiving downvotes either. I guess a few folks are angry about having their business model attacked with reality.
Addressing your post: Software isn't a car and the marginal cost to manufacture more software licenses is zero. When I direct an hour of effort to our commercial software, I'm gaining many dollars of future passive revenue thanks to that created wealth.
Contrast that with services and a 'free' product, where each hour of effort gets a support dollar but generates no wealth at all! Pitted against that means of generating revenue, a service company giving away its product is going to lose in the long-run every time.
To see this, just look at the software marketplace: Aside from the solitary black-swan exception of RedHat (which arguably sells licenses instead of services anyhow), where are the profitable open source support contract companies?
I can spool up 3,000 software licenses sold today without batting an eye (and add in support charges on top of that if needed) making a ton of cash with which to hire employees for product improvement, but 3,000 hours of support is a huge cost requiring a great many employees to manage before even a penny of profit is obtained.
Bringing this back to my original point: Commercial software companies can easily dominate 'free' open source alternatives given that reality, so they can safely ignore their free 'competition'.
RedHat doesn't really sell support. They sell licenses, enforced by their trademark. They provide support for each license sold, that's true.
People buy RedHat licenses because it's a defacto standard in the industry. Some people or companies use CentOS, which is a re-branded RedHat. But if you want the original, you have to buy the product.
So why do they buy the license? CentOS is 100% compatible with RedHat. There is no reason to buy a license other than if you want the support they offer. RHN is part of that support.
Because managers need a line item in the budget to do anything, and it's a lot easier organizationally to pay a yearly subscription (no matter how expensive) than it is to make it an employee's job.
The support basically amounts to access to their RPM repository. You'd have to pay a lot of money to get access to Alan Cox -- normal tickets just get you access to people who've been through the same training that your manager paid you to go to.
You're forgetting a second perk of paying for an item with support: You get to yell at someone when something goes wrong without having an HR report filed against you. Passing blame and responsibility for "opportunities" is standard enterprise behavior.
I agree that it is quite difficult to scale support; but that is even more true for closed source software. Open-source software, at least, has plenty of 'free help' in the form of searchable web forms and mailing lists.
That '_commerical_' support you're referring to doesn't scale worth a damn
Yeah it does. Instead of having a single official company to go to for support, you can go to multiple ones and choose the one that fits you. Competition is a good thing, right?
The parent was referring to "scaling" for businesses, not consumers.
Competition is good as long as it's driven by quality, not price. A competition on price can be good for products, but then again, it's only good when your lowering the price by improving the quality of the manufacturing process ... I don't think anyone will be happy if Apple goes bankrupt or stops producing IPhones because of cheap knockoffs made in China.
In the case of support, people only want to pay the minimum amount they can for their needs to be met. If you want to provide quality services, you'll have a hard time doing that when your customers will discover that they don't need it and outsource their operations to India.
This happens because few pieces of software really need paid support. For an open-source project, in many cases you'll get better support from its mailing list than from a commercial entity. Only companies with enough money will pay for high-quality support ... and they'll only do it for peace of mind and for passing the blame. Not to mention that B2B products are quite boring and support can also be provided by cheap labor.
Tom didn't say anything about the availability of support options. It's very simple. If I buy something, I know that the vendor is interested in making me happy to some (sometimes minor) degree. If I pick up code that someone dropped on github I cannot make that assumption.
So the two models default to different basic assumptions and that has nothing to do with support contracts being available or not.
No, not at all?
Just because commercial software can and will be catered to the users specific needs, doesn't imply the user always wants to make any form of financial contribution to the desired result.
Nine out of ten times, if you want something, Users tend to google it to look for a share/free/OS version, before they fork out the cash, and if they are lucky enough to find one and get it running, It's always the coders fault that they can't quite make it work for their needs.
not necessarily. businesses can (and do) target customers who work best with the business model they use. I know I have something of a barrier to entry for customers; if you can't figure out how to use an OpenSSH public key to authenticate your access to a serial console, I refer you to linode or slicehost. I freely admit I am unprepared to support those users, and probably could not do so at my current prices. And my competitors are good; I haven't heard anything bad about either one.
Sure, I could have more customers if I had an easier way to control your VPS than a ssh-based console, but at what cost? People who know Linux are pretty easy to support, once you give them (standard linux) tools. There are enough people who understand (sometimes even prefer) the standard linux tools to a web interface to support my business, so I say, why not offer them a service at a price that reflects the lower cost of supporting those users?
(right now my big problem is provisioning; that is, if you want to add services, you need to wait for an employee of prgmr.com to help. But most everything else, the user can do without my help.)
I think forcing your support people to stay on the line with rude or difficult customers is a good way to burn out your support people. I think having a liberal but well-defined money back guarantee makes doing support quite a bit easier. Keeping good customer support people is hard - I think losing the most difficult 2% of customers is a small price to pay to keep good support people for the rest of your customers. And really, I'm not in the business of tricking people into giving me money. If we aren't what you expected, then yeah, I'm happy to give you a refund.
I think an important question is: does it matter to me how many people use my (open source) software or not? And it seems to me usually it does matter. More users means higher likelihood for other people to provide patches. It means higher esteem for me, which should translate into higher consulting rates. Therefore I don't quite get the "fuck you, customer" attitude. If you don't care, why even bother to open source the software? Just keep it private on your hard disk.
(Note: I didn't read the whole rant. Presumably there were some obnoxious customers. Whatever - how likely is it that they read his rant and change their ways? Not very likely imo).
I make some of my code available for others to use as they will. I do not consider myself to be an open-source developer. I really don't care how many people use it, but it's nice that some people find it useful. I have the code, it costs me nothing to make it available, and others think it makes their world better, so that's OK then.
I don't have an aggressive "customer" attitude, but I get pretty annoyed when someone who uses the software then demands that I change something. Not request, not suggest, not offer to help, but demand that it be changed.
I'm not looking for more esteem, better rates, "karma" of any sort, I'm just happy to make it available because I think the world can't be worse off, and might be better off. I really, really don't care how many people use it, and what is clear is that keeping it private on my hard drive means that there is no chance it makes the world a better place.
You don't seem to be able to comprehend the idea that people will sometimes just make their work available to others without any desire or need to recognition or compensation. I think the world would be a better place if people did.
"You don't seem to be able to comprehend the idea that people will sometimes just make their work available to others without any desire or need to recognition or compensation."
If that really were so, then why the rant? So a part of you seems to care. The "demanding" customers are basically just dumb or socially challenged, so I would pity them, not write a long rant.
First of all, your use of "you" immediately after the reference to the long rant seems to show a confusion. I'm not the author of the long rant, although I'm in largely the same situation. It's not especially relevant that I didn't write the linked article, but I thought I'd make that clear.
Secondly, it may be that you didn't intend it, but your first sentence is calling me a liar. I object to that, and ask that you withdraw it. It is so, I say it is so as a matter of fact because I am one of them, and while you may legitimately express doubt, starting a sentence with "If that were so ..." (emphasis added) is calling me a liar, and I think it's out of order.
Thirdly, I really don't care if people use my code, but I really do care that some people then behave in the obnoxious manner that they do.
You may be sufficiently socially disconnected - I don't know if you are, but you might be - to pity people who do the internet equivalent of repeatedly spitting in your face, but I'm not, and I object to it, especially when they use my work.
Oh dear, I guess if we were in a bar we would now start a bar fight and hit each other over the head with beer glassed? Sorry if I hurt your feelings, and no, I did not intend to call you a liar, just probing a little. I see a degree of difference, but it is not important enough to me to have a fight over it.
Anyway, sorry I even chimed in onto the conversation. Obviously people have different reasons to publish their stuff.
> Oh dear, I guess if we were in a bar we would now start a bar fight and hit each other over the head with beer glassed?
If we were face to face I suspect it would've gone completely differently. I don't think you'd've said what you did in the way that you did. I was simply trying to point out that you were, in my opinion, being rather more aggressive than perhaps you thought.
I accept that you didn't intend to call me a liar.
I'm not sorry you chimed in. I haven't down-mud you because I think you have added value to this thread. You have expressed a point of view. I think what you said was wrong, and I've supplied my point of view as a counter to it. The thread has been longer than I'd've liked, but that's the way it's gone.
I hope I've expressed myself clearly enough that you now understand my position, even if you might not agree with it.
The "fuck you, customer" is often a different way to raise esteem. The feeling is that if others read about how badass you are at not caring what others think of your projects, they will think you're badass and ask you to do contract work for them. Presumably they'll realize that only a really really uncaring badass person will write a long screed about how they really don't care.
(gah, the original post is such a long exercise is self-important posturing! Complete with careful recitation of all the opensource work he's done. And then I followed the link to the bio site to learn the guy does "Agile coaching". At that point I even briefly considered doing a facepalm gesture).
A "license" like that would be a good thing, I think. Whenever I hear about some potentially useful-to-me 0.1-version OS project, it'd be nice to know things about it. Things like, "Is the developer ever going to spend more than that first weekend poking at it?" or "Does the developer think of this code as similar to a discarded toilet he's left on a curb?"
I get the point about entitled-feeling users, but there's a flip side: in the comments, he goes on about welcoming bug reports, etc. from those users. He wants users to bug-test for him and help him improve his code, but he's not paying them for the QC work any more than they're paying him for coding.
If you release software, for better or worse, you set up some social expectations. If you don't want people complaining to you and wanting bug-fixes and support, either don't release that software or make it abundantly clear in the license, download site, etc. that the software isn't supported.
Hilarious...That's like complaining about the food at a homeless shelter. Its free and, in this situation, unsupported. Buy a commercial product if you want above and beyond customer service...
He's not an open source developer. He's someone who writes code for himself, then makes it available to people in case they might find it useful. I think that's different.
> ... is complaining about his open source customer ...
"Customer" is an interesting word. If someone leaves stuff around with a sign saying "help yourself" and I take some, am I a "customer"? No, I don't think so.
> ... complaining about his code.
I don't think it's the "complaint", /per se/, I think it's the tone of the complaint. I've had this. People have picked up stuff I've chosen to make available, then they've demanded I enhance it in the ways they want. Further, their demands border on the threatening.
I just wish more people would make their work available, fewer people would make demands, and that people in general were more constructive and just tried to get along.
Unusually extreme climactic conditions in Hades seem more likely, though.
He's someone who writes code for homself, then makes it available to people in case they might find it useful.
That actually sounds like an excellent definition for a big fraction of source developers. One of the many benefits of open source is that it captures and aggregates value of even very modest contributions as well as the value of major contributions.
I'm curious what would make someone an open-source developer if ~"writing code and making it freely available to people"~ is not the chief qualification.
As far as I can tell, its not the "Open-source" portion that is debated, its the developer portion. I have written a bit of code which I share around (and I think I'll actually start using the WTFPL license on it), but I would never consider myself an open-source developer. For the most part, its all code I threw together in an afternoon or a weekend (or, in one case a week of afternoons), and I thought "someone else may want this, so I'll make it available to them".
To make this clear, I am not a software developer. I'm a college student/tech support person who just happens to write some semi-useful code. Its not software, there's little-to-no documentation, and I'll only be supporting it if I think the problem is interesting.
In my mind there is a continuum between two points.
1: Those who write code specifically for the purpose of making it available, possibly originally because they wanted it themselves, but now because it's been made open, people are using it, and they're deriving some sort of (possibly intangible) benefits from it (karma, esteem, recognition, PostCardWare, whatever)
and
2: People who write code, often small scripts or functions, purely because they need them, and, almost as an afterthought, make them publically readable with no thought to getting anything in return, but simply because they think the world would be a better place if more people did that.
In linguistic terms, the concept of "Open Source Developer" has, in my mind "baggage". Your semantics may differ from mine, but to me, there is a distinction to be made.
To me an "Open Source Developer" is someone who is paid by an interested big-corp to work full time on a project that's open source: there's lots of them at Red Hat, Novell, Canonical, IBM (ASF crap especially), Intel, Sun, Apple, etc.
It's distinct from "scratch your own itch" stuff, especially when it's a project or a feature you wouldn't otherwise work on.
I guess one problem is that expecations of users of OSS are not just a thing between the developer of a particular piece of software and its users. The open source movement has been busy creating expectations of OSS being better supported, higher quality software with a commercial business model.
All the big corporations supporting open source by making code available also change the perception that open source is some kind of grass roots non-commercial thing. The single developer of some open source library may in fact be on the payroll of some BigCorp playing some kind of advocacy role for which he is being paid a salary.
You don't know unless you dig deeper and some people don't dig deeper. They just work on the basis of general assumptions formed by the collective advocacy effort of the open source movement as a whole.
Of course that doesn't mean an individual developer has to honor that collective promise. I do understand that guy's rant. I'm just trying to explain how such misguided expectations can arise.
The conclusion, for me, is this: Don't use open source software unless you don't need it and could build it yourself, unless you know why the developer has a vested interest in making you, the user, happy.
Dear self-important open source developer: I have never heard about you, and I don't care about your little private project. Good luck with your freelancing work.
P.S.: either you a) don't care what people think about your project, then why the rant or b) you care, then why the rant?
Usually, frustration is rooted elsewhere. The person has something to do, and is annoyed that it (still) can't be done, probably after trying my project along with a number of others. I try not to take this personally.
So my first response is to be civil. I don't even talk about anything mean they might have said, I focus entirely on the problem. I solve that problem, and say "here you are".
The response to this has always been gratitude, and even amazement that I solved the problem. It seems that once the person reaches the point of yelling at a developer, that person has given up and doesn't really expect anything anymore.
A community is built one person at a time.