Slashdot Mirror
Commercial Support for Open Source Products?
dot.not asks: "For the first time I am involved with a commercial product that is considered 'open source'. We are now facing the question of support. I have no experiece with support on Open Source products, but I do have some thoughts. I can imagine that the product is only supported unless it is implemented unchanged, but then how do you track this? What if a piece of unrelated code is changed and the customer finds a bug in another piece of code? Who / how do you decide if this is covered under support? Your thoughts and experiences?" This is an interesting problem. How far do you support a codebase that may be modified and extended by the people who use it?
I was going to start something akin to this, basically you would have the developers sign up to support their software, they set the price and services all in an online app (ala guru.com). it would basically be a big online ticket/support system where incidents can get charged (one time) or people could buy blocks of support. Everything would be configurable from the developer standpoint.
:)
Unfortunately I have 0 time for such projects (employed full-time and any spare time gets sucked up by other OSS projects). I do think it would be a viable option for a business to create this type of middleman/support management scenario, but it would also require someone with a bit of law experience to construct the contract so that developers don't just take the money and run (especially in international circumstances).
If anyone would like to contact me and perhaps bounce some ideas around, feel free to email me. I can't promise I can work on it, but if enough people get involved, perhaps it could be some type of open source business initiative, where everyone wins, well ideally
The moderation system is broken. (yes, it's been broken for a long time, but this time it's actually broken.)
A few days ago, mod points, for some unclear reason, stopped getting distributed. The only moderation taking place was negative moderation, mainly directed at the _spork community, probably done by hand by one or two of the editors. Many people are assuming that the sudden increase in sporks caused an excess load on the moderation scheme, causing it to break in the first place. The solution to this was an increase in the time between comments (2 minutes instead of 1), and a heavy dose of new mod points once they realized the problem. Unfortunately, it seems they've been giving out too many mod points (I've gotten 15 in the last 24 hours), and people are wasting them because it's convenient. (more ambitious people are targetting some worthy targets: SpanishInquisition received 10 of my mod points, which probably explains why he is not posting today.)
So yes, slashdot had some issues, the weird moderation is the upswing up that. I believe once the system believes that a large enough percentage of the overall stories have been moderated, it will start slowing down again. Until then, deal with it.
- Anomymous_Spork, posting via proxy because of a bitchslap.
You ask them to reproduce the problem with some known stock version of the codebase, to rule out the bug being caused by the modifications. Or otherwise demonstrate that it's a coding problem that exists in the original codebase. After all, when the fix is found, it will be applied to the development stream which doesn't have the customer's modifications.
Users who are competent enough to extend the code
are usually competent enough to also find bugs and send in reports with patches.
I think that to obtain support for a patched version, the users first have to work with the developer to have those patches incorporated into the software. The patched program then becomes ``official'' from the perspective of the vendor, and is supported as such.
Of course, a support agreement can be worked out regardless. The customer should be able to request assistance with a patched program; but the customer then has to share the patch with the developers, and compensate them for the time spent understanding the patch. This would only make sense when there is a problem with the patch itself; the customer tries to extend the program but dig themselves into a hole, so to speak.
Then charge them for it! If they've modifications, it's that much more billable time you can spend tracing what they've done. You can optionally do an md5sum of their binaries and charge an extra fee for modified ones if you wish, but my advice is just to go hourly. Denying support to a (potentially) paying customer is usually not very good for business. ;)
And remember, depending on your license, their changes may be available for your use, so there's free coding there you can possibly take advange of
Your company provides support for the binary distribution you provide (as part of the sale). If the customer wants support for a version compiled from source, the support is provided with an hourly fee.
This is exactly what I do at my company. If there are any modifications to the code, then instead of being a support issue, it becomes a consulting issue. We check the binaries before we even begin by ssh'ing to the machines (we make servers) and md5summing the appropriate libraries and binaries.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Is to have them register their copy (free) with you, so you can support your own version, downloaded from your own site (or installed off of your own CDs).
Every CD should come with a little piece of paper saying "Unique User ID #xxxxxxxxx" which is some unique random hash number.
Every time you click the "download" link, on the web page, it should say "Write this number down: #xxxxxxx" and give you a unique number.
You then go to some other web page, plug in your unique id (regardless of the method attained), and plug in your name, maybe your email addy, something that identifies you.
Then your service rep says "May I have your name and product ID number?" If the info checks out, then they serve ya....
(I'm basing this somewhat off the way that Dell does hardware support; they ask me for my ``service tag number'' and then for my name/address..)
-- Aaron Kimball
The traditional way to deal with this problem is to distribute binaries as well as source code, and only support customers who can reproduce their complaints on verifiably original binaries. That's what everybody used to do back before the closed-source era. (Yes, that's right, open source came first -- as late as the 1970s IBM was still distributing source code to their operating systems free to all users. Software was viewed as a loss-leader for the hardware. Only with the advent of `unbundling', the separate sale of hardware and software, implemented to satisfy anti-trust complaints, did closed-source become a common feature of the software business.)
-Tom Duff
Take the MD5 hashes of all the files as distributed.
Modify the hell out of the files in a stupid manner, as customers often do, breaking them miserably.
Call support. When asked for the MD5 sum, make clicking noises on the keyboard while you read off the original numbers from your notebook.
This is no different from the debates over cheating on network games. All of the posts that say, "Well, only support the unmodified program," fall into the same trap as the posts that recommend only allowing the "approved" game clients to connect to your server -- clients/customers will happily lie their ass off, either in voice over the phone, or in checksum packets over the network.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
How do you do the support? You can choose! That's the cool thing. You can stipulate that you only support unmodified versions, or you can take on a bigger challenge and say that you'll support customized versions as well.
But there's nothing to say that you *have* to support customizations, or even releases after some release you specify.
The more flexible you are the more your customers like you; the more flexible you are, the more you have to pay your employees. There's a happy balance somewhere for any given company, and the balance point may be different for different companies.
All opinions expressed herein are not my own; I haven't had free will since last year when aliens ate my brain.
Since many open-source business models rely on customers paying for tech support, only give real, corporate-level support to the official package that came from your shops.
However, don't stop your developers from helping answer questions on your product's development list. There's a difference, I think, between J. Random Hacker looking for a little bit of insight on the code he's trying to integrate with his OSS project, and a company buying your software, customizing it to hell, and then demanding your support.
Maybe include a clause in the support contract specifying different rates for modified software.
Karma: Bored. (Thinking about resurrecting the "Anyone else is an imposter" joke.)
Like many people (I suspect), I read Slashdot mainly for the posts. Some of the most informative pieces are those in which one of Slashdot's editors have made a factual error, and the community summarily slams him/her (are there any "hers"?) for lack of journalistic integrity. We get 3-6 +5 posts that seem to be written by experts in the field and are very informative to neophytes like me.
But if we suddenly have like 25 +5 posts per thread, the signal/noise ratio goes WAY down. Come on, 59 +5 posts in the SDMI story? WTF!?!?! They really weren't all that good.
Did Slashdot get cracked? Did they change the moderation system? SOMEBODY CHANGE IT BACK!!!
Thanks for listening.
If you're not wasted, the day is.
If you're not wasted, the day is.
What kind of support are you talking about? Are you talking about loozer "warranty" support, where you charge some moron $55 bucks every time calls you up and complains that he's unable to follow directions, and it's pretty clear the problem is in the interface between the chair and keyboard? Then get some monkeys to answer the phone, get a credit card before you do anything else, and refuse to help if the code is changed in any way.
Or, are you talking about real support, where the customer gives you enough money to buy a house, and the customer views you as a worthwhile partner who will help the customer find technical solutions to their business problems? If this is the case, then you had better expect the customer to change the code. They're paying you damned good money help make your product more useful in their environment, and you better be willing to do something for that money. If their code monkeys keep breaking the code, then increase your price. If you get to the point where you're charging them obcene amounts of money, but you just get sick with them, then drop them as a customer and lay off a couple of engineers.
I have to be honest, though -- I'd sooner boil myself alive in acid than I would try to provide $55/call incident support on just about any software. It would be even worse on most of the open source stuff I've seen, where you'd undoubtedly get just as many moron users, but a disappointingly high percentage would be both: 'l337' (i.e., still a moron, but blissfully unaware of the fact), and 'poor' (i.e., no business credit card to wave around).
Slashdot is jumping the shark. I'm just driving the boat.
While that's true, degrees of support are by no means fixed. In some ways, not supporting open source code if it's been modified is like Gateway's voiding warranties on boxes where the user installed new software. Maybe the client is choosing your open source based solution because they want to be able to tweak some code.
I don't think you should cut them off entirely. You'll just need more skilled support staff who can determine whether new changes are causing their problems, and if those new changes fall within the scope of your support.
You'll have to make some new rules here.
Reread the original question and decided I was too vague.
How do you track if a product is implemented unchanged? You can't. You use the version ID number that came with the product.
Sure, they can lie about the version number or not changing the code, but that won't help them, and they are paying you per hour, as per your service contract, right?
This can be *confirmed* as simply as saying "We've replicated your setup and can't find the problem"
or
"Give us access to your setup so we can see what's going on."
What if a piece of unrelated code is changed and the customer finds a bug in another piece of code?
The unrelated code is irrelevant, then. Fix the bug, supply a patch, and incorporate into the product. Or document the bug and workarounds.
Who/how do you decide if this is covered under support?
Write a good support contract, and then prepared to be flexible and helpful. Customer satsifaction and all
Geek dating!
GPL Deconstructed
Support is the wrong term for an Open Source product.
You provide the source, so the only support you can provide is... how to open it in a text editor, how to compile it, how to modify it, how to check out and check in. In the sense that the Source is it's own product and all.
Support for the binary and all is no different than any other product; the source acts like documentation, which is all the difference...
"So I'm using version 3.X.X.Y and keep having this problem, with this trace and dump. We looked at the corresponding source and found this <description of problem> but dunno if this was it. When we recompiled with <this fix> the problem went away, but we still have <portion of problem>"
In this case, the Source is being leveraged by the customer, and you, against the product, making the product that much more useful and useable.
Does this make sense?
I dunno about a company buying your software, customizing it to hell, and then demanding support. If that company wanted support, it should be purchasing a support contract, with full disclosure and documentation of the changes and customization to said product. In the end it makes your product more useful and customer oriented and it makes your support issues easier because you have essentially outsourced a full development team at no cost to you for a new flavor of your product
Geek dating!
GPL Deconstructed
Support the binary version of the product.
That's what you sell, that's what you produce.
The Source is available for everyone to access, use, compile, tweak, etc.
To be clear, make this kind of separation:
Branded binary release of an Open Source product. This is sold/given away/whatever, and this is supported. Each binary should have a ID, a version number or tag, such that your support organization can track and file problems against this version.
The Source itself has it's own, different, versioning scheme. Allow for forums, mailing lists, and chatrooms for this, different, product.
In a way you can treat the Source as a document describing and explaining the product; but treat the product like any other closed source product, and support it as such. If people have problems with the Open Source product, well, the whole point of Open Source is that they can and should fix it themselves. If they can contribute a fix, review, give credit, and incorporate.
If they find a bug or problem that is big enough that you *should* fix, then fix it, credit, document, and incorporate.
The point is that the product is not free, but that the Source is
Geek dating!
GPL Deconstructed
(end comment) */ }
(end comment) */ }
[an error occurred while processing this directive]
The support agreement might work like this. Your company provides support for the binary distribution you provide (as part of the sale). If the customer wants support for a version compiled from source, the support is provided with an hourly fee. This way you have not completely elminated the possibility that a user would compile his own version, but you have reduced your liability. The installed version would have to be varified via MD5 checksum or some such mechanism prior to initiation of the support session.
-- CTH
---
--Got Lists? | Top 95 Star Wars Line
Let your customers participate in the design and development of the software via sourceforge or that sort of thing.
That means, however, that their own changes might be used by others (the competition perhaps), and by others who follow later on.
But I don't see how you could chage them for that.
On the other hand: you could have them make modifications to the code on a non-production machine, and send you their modifications for approval/review/editing. Then, you would maintain a copy of their modified source code. All this would have to be rigorously documented, of course, but that's a solution which you could charge for.
"Piter, too, is dead."
I'm not sure why you think this is so complicated. If the customer has definitely traced the bug to the original code, including conditions required to elicit it, and you can replicate the problem, then you should take responsibility for fixing it. The customer has already handed you pretty much everything you need to find and kill the bug anyway, and squashing it now saves you having to fix it for future expanded releases or code re-use.
If the customer's coder hasn't definitely traced it to your code, the customer dropped the program in your lap and said fix it, and you have to take the time tracing through the custom routines, then the customer should pay for support, even if the bug eventually turns up in the original code.