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