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?
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.
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
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)
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.)
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
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