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?
As a side note, I was recently trying to implement an open source product into a commercial product I'm working on. End result, I was needing to directly access the CVS and hope that this code wouldn't change again by the time they made another formal release. It seems that bugs spread reapidly with the introduction of new features, don't know if that's a common problem or not but mailing lists and CVS dumps really made my manager uncomfortable. Result, my implementation was tossed
There is a company providing commercial support for snort. Perhaps they can give you some insight.
THE file? name 1 app more complex than "hello world!" thats 1 file.
I'm employed in a company who does exactly this. We only support the official distributed version. However we try to help customers who are doing customization of the product. (this we charge for ofcourse) Usually we end up with the user trying to implement something that we would want in the main distro so we encourage them to pay us to do it or send us the patch when they are finnished.
Most of our customors are pretty smart people and they seem to understand that it is difficult for us to support a product that they have tampered with. So any big changes/addons are usually done by us.
This has worked very well so far, and for the special cases where people are demanding support way beyond anything normal we have a clause in our contract..
The vendors are charging for their support work, not your development work. You already gave your development work away by releasing the source code. If you want to make money from development work in OSS you must go into support contracts or find some other profitable sideline. If you want to make money purely from working as a developer then for Christ's sake DON'T GO OPEN-SOURCE.
All of the people here are usually "Open Source Rulz dude!" but then when it comes to supporting the BIGGEST feature of all of Linux (It is customizing the source for you dumbasses out there that don't know) you fall back and say you won't support it ?? What the fuck! I should be able to put while(1) { fork(); } In some Kernel code recompile and pay RedHat $195 to track it down.. Practice what you preach!
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.
Where's the value in modifying a GPLed program for yourself when you know damn well your own work and expense is making your vendor more money while you get no added benefit?
By the same token, what's to stop you from rolling all of your mods into a binary and selling it?
Even if we discount that possability, at least you got exactly the features you wanted, when you wanted them. No vaporous RSN from your vendor. You'll never be forced to live with a killer (for you) bug that the vendor decides isn't important to enough of it's customers to bother with.
Perhaps you can sell the mods back to the vendor. If you don't distribute the binary to outside parties, GPL doesn't require you to distribute the sources either. If the vendor isn't interested, you could try selling the mods directly to their customers (with source, naturally).
Short summary, if you're an end user, sell back to the vendor. If you're a reseller, re-sell!
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.
I don't know if there are any exist scheme, but it seems pretty simple to me. When somebody buys your code, you support 'your code' out of the box. This may be the standard 30/60/90 days of support. I would assume you ship binaries as well as code. Have the user send you an md5 of the binary/binaries in question. You could ship a script to simplify this for the user. This way you can verify it is your code and not waste you customer's time.
You can also provide special coverage plans. Thing that provid ethe same coverage as above (shipped code only) and maybe other plans the allow for various third party or inhouse sources.
Overall, by giving the customer the source, you are giving them a lot of power. You cannot be held responsible if they abuse it.
Dan
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
I also recieved moderation points twice within a one week period.
It's simple. Make a proprietary binary file that md5sums a different file depending on the day of the week, appends the date to that md5sum, md5sums the result, then cats the date string to that md5 sum and returns it.
The support guy types in the the string that the proprietary program cranks out and voila! He can re-create that number using the supplied date and the hidden knowledge (that being what file is associated with the time string supplied).
Of course there are knuckleheads who are going to try to get something for nothing (ie consulting services for the price of support services). You CAN be smarter than them.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
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.
You're selling support, right?
If someone wants to hack your source and make you help them, let them pay you! You just charge a lot more for it. It seems like the proper answer is completely clear cut. You have different tiers of service, and the higher tiers get to talk to your coders and get advice. The lower tiers get advised to download the latest RPM. Totally straightforward.
--
There are no trails. There are no trees out here.
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
Most definetly! Buy the binary, keep the source. That way if the vendor goes belly up you can be rest-assured that your application won't die along with the vendor.
I'd imagine that the vast majority of customers out there don't want to mess with the source at all. Just because the have the ability to tweat the code doesn't mean that they necessarily will. I think that I'd be correct to assume that if a customer has the technical ability to tweak the code they won't be the type of customer that will typically call tech support.
MD5 Hash of the file perhaps?
I stopped moderating some time ago because I was tired of getting dinged in meta-mod by people with dual accounts for moderating down off-topic ACs and flamebaiters.
siri
No, you can't. The person will just run the proprietary binary against an unmodified *backup* of the *original* code. Client-side security is impossible.
Become a FSF associate member before the low #s are used
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
Before I actually respond to your post, I just want to thank you for your Device. That is truly a work of art.
Anyhow, I posted a comment mentioning why this won't work. It's way way down the page attached to a score=2 article, but here you go.
Basically, the problem is client-side security. I fully agree with the rest of your thoughts, however.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
Yeah but just think of all the K-whores who are now pissing blood cuz every one and their goat posts at 2 now.
There are companies that specialize in the ongoing support and maintenance of custom code- open or closed. I know that the majority of business for these groups comes from clients who have implemented closed software, but there are a number of projects that sit on top of open source foundations.
A link to the management service providers website.
disclosure: I happen to work for a company that is part of the MSP organization.
Name a contacting job that doesn't do that with estimates?
The message on the other side of this sig is false.
Flamebait? What the fuck?
By having people willing to pay to have their changes supported just like mechanics fixing cars fixed by other mechanics you make a buck and you can even go independent fixing other people's code.
And hello users YOU GET CLOSER TO OWNING SOFTWARE!
The message on the other side of this sig is false.
solution I've seen yet. Congrats.
All these don't support the changed source are going to keep the age of software warranties further away. If people start offering support for others work look at what could happen:
Code reuse - cheaper to change something that works and is known
Reverse engineering properly regarded as a desirable and necessary field of study
Software ownership - if it's easy to support than it should be easy to hire contractors to fix problems which means people will demand to be able to choose who fixes their software which is very close to what you get when you own a car
All this and more for $19.95 (I would love to work with a group to create this but I am somewhat sceptical hence the as seen on tv reference)
The message on the other side of this sig is false.
Hmmm. I'm gonna wind up reversing a troll mod by posting this, but oh well.
It would be a simple matter to have posts at, say, +5 be docked 1.5 mod points (staying in integers; it would have to be modded down twice from +5 to get the other -.5 which would bring it down another point). Or you could make it easier to mod a post down based on how the poster's other comments have been modded. Or have each +1 addition to a comment increase the poster's karma less if the poster already has higher karma. Something like that.
Hmmm. You're right. I missed the point.
/. would either stagnate or go into a karma sinkhole), but it would probably skim some of the overvalued posts from the top of the heap.
Still, you could assign a random integer to how many mod points somebody gets each time he/she mods (say, a random integer from 1-10). Failing that, I think it would be interesting to see classes of mod points (say, be given a random number of +mod points and -mod points; the +mod points for modding stuff up and the -mod points for modding down). That would keep the rampant +5/karma runaway problem from growing much more than it already has by limiting the amount of karma that can be generated. There would have to be limitations on the random numbers for mod point allocation as a whole (preferably somewhat more +mod points than -mod points, otherwise
Or the moderation system in /. is breaking down because there is too much Karma running around. I'm not too familiar with the way /. works but I have noticed that after one or two comments being modded up (by just one point) the poster gets moderation points to play with. It is conceivable that this system would snowball if the points are spread evenly enough to create more moderators who in turn would rate up more people and thus create more moderators - lather, rinse, repeat. The result is /. meltdown with +5 comments everywhere. One reasonable way to stop this is to enforce a global moderation point limit as a function of the number of comments.
Anybody actually know that this kind chain reaction can't happen?
The basic problem is that one +1 mod creates 5 new mod points. This is classic runaway chain reaction stuff. In whole, the moderation system seems inherently unstable. If everyone mods up, everyone gets points and if everyone mods down, no points are rewarded to anyone (which probably explains the moderation guidelines...)
An elegant solution would be to create a variable number of given mod points per +1 mod based on the current ratings in the system. My guess is that you probably want to keep the threshold low (+1 mod point gives x moderation points no matter what), otherwise the system would run out of moderators quickly.
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.)
Give them a pre-compield binary executable and specify that the contract is for that only.
You are absolutely right, my post is offtopic.
You are absolutely wrong, it's not a crap rant that needs to be modded down.
Where on Slashdot is meta-discussion supposed to take place? In the three years I've frequented this site, I've never once seen an open-ended "Let's talk about Slashdot" article. And that's fine: Slashdot is about news, not introspection.
But I truly believe that the over-moderation phenoemenon of the last few days is a treacherous step in the wrong direction for Slashdot. And I think that it deserves enough attention to warrant breaking the rules and starting an off-topic thread.
If you review my posting history, you'll see that I haven't posted very much recently. That's because when I don't have anything to say, I keep my fool mouth shut. But when something comes up about which I am knowledgeable or feel particularly stronly, I will certainly post.
Please do not accuse me of being a troll. I'm not.
If you're not wasted, the day is.
If you're not wasted, the day is.
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.
there has been some discussion of this latley around werk etc
postgres has support
mod_perl you can even buy support for
im sure this is an industry waiting to boom
back in the day we didnt have no old school
Your first question should be "did you recompile from the latest sources??" Hey, it works for my helpdesk. "Did you reboot?".
witty sig goes here
Now, I can't find anything that hasn't either been modded up too much already or modded into -1 land. Its been two months since my last set of points, now I don't know what to do with the ones I have.
You've got to love the fact that the site with the largest tech community also updates their code, on the fly, on live servers. It wasn't cracked. It is a simple case of them installing untested code on their live site. They will then tweak the code until once again they acheive the balance they are looking for. Its pretty amusing, but for those of us looking to glean a little knowledge(of both what to do and what not to do on a site) its also pretty informative.
No, Thursday's out. How about never - is never good for you?
So all the support department needs to do is ascertain whether the customer is using a virgin copy of the product, and if not, support will be limited to the unchanged part of the code. The headaches that come with supporting factory-supplied stuff working alongside customer-supplied stuff are part of the territory - nothing new here.
I think that probably the blame would fall on whoever changed the code....I certainly can't see the distributer (ex. RedHat) being charged with the problem, because they supplied a product that works. I think that once changes are made to the software, it is out of the software maker's hands.
I also don't think that opensource programs can really be held responsible for any programs that don't work, after all, you could have checked the code for bugs...so it would not necessarily be their fault.
The anti-salmon
"The more you want to fuck it up on your own, the more you'll pay to have it unfucked"--even to the point where it would have been cheaper to hire your (the vendor's) programmer/consultants in the first place. You'll just have to be OK with leaving that decision in the hands of your customer.
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.
It means if they can tweak the code, it means when they do call tech support, they already have the problem and solution firmly in hand, but don't have the resources, means, or capability to fully thresh out the solution.
A side benefit is that if company B mods the hell out of the product, we've created a second product by effectively outsourcing development to company B.
It's a different issue whether we can create a new product with said mods, but the issue would be the services and such company B is providing with software, and not the software itself
Geek dating!
GPL Deconstructed
So I release an Open Source product, say some sort of load balancing software, and I sell network devices that use this product.
Company B who buys my products and rebrands them to create their own variation of network devices is free to, and does.
Company C buys my products in order to use said network devices.
Both offer fixes and patches to my software, being Open Source, and both gain the benefits of using my software and products. What's to stop us from taking the software of CoB and creating a new network device?
Morals, I guess. On the other hand, it would make sense that CoB's mods are device specific, and essentially forked off from my branch. If I were to re-release them myself, I'd need to redevelop the hardware that CoB uses.
If there is no value in modifying a GPLed program, you wouldn't modify it.
If there is some marginal value, then it's worth modifying.
This is very similar to the current situation between Handspring and Palm, but instead of GPLed software we have licensed software. On the other hand, you can ask the question "Why should I release my software's source if company B can take it, make improvements, and sell better devices?
The added benefit is almost raw, unadultered competition. Whatever benefit CoB can add is the profit you can make. Whatever benefit I can add is the profit I can make. If my GPLed software didn't exist, CoB would be forced to reinvent the wheel. If CoB can release a product with my software that I cannot win against CoB, then, well, shame on me!
Geek dating!
GPL Deconstructed
I'm not sure I get your point;
As long as the contract is well defined and specified about what the terms are, what's billable, what's required, what's requested, and what's supported, there should be no issue.
How much money is being exchanged? What services will be provided? What resources?
That is independent on whether the product is Open Source or not, the only difference is in the implementation in that the client has full access to the source, as it were.
Geek dating!
GPL Deconstructed
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]
Maybe the client is choosing your open source based solution because they want to be able to tweak some code.
Okay, but if they then ask for your help, the client is choosing your open source based solution because they want to have the freedom to tweak some code and then have you tell them how to untweak it. For the amount of money that they'd have to spend to get someone to help them in this way, they might as well hire a second programmer who can specialize in this. Unless it's like how it is at my friend's place, where people spend upwards of five to six figures a year on support contracts, I can't see how this could be properly implemented.
Programmers who are any good and can help customers in this way don't stay on the help desk very long. I really do think you're asking for trouble by having your help desk serve as a mod consulting service.
Once again, I think questions about this sort of thing are okay, so long as it's based on the original source code. The company could actually be of some real help here.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Actually, a quick read further down suggested that he should go for it and just charge the guy out the wazoo. I like that idea. If it'll get open source out there and more money in the hands of the programmers, it might have benefits that stretch to free software (if software modding as its own industry ever takes off).
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
Your responsibility to provide support should end the moment the product's source code is tampered with by a customer. You can't be held responsible for what they do, unless you want to start answering questions for every single fork that's ever happened...
Besides, if it's open source, the guy should be able to revert back to a product's code base that you'll be able to help him with, no?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
The solution to every problem the user calls for support on is to re-install the binary distribution your company provides. That way it doesn't matter what the customer did to the source.
---
--Got Lists? | Top 95 Star Wars Line
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
-
For unmodified products, charge per incident as is always done.
-
For modified products, charge hourly for a technician to diagnose the problem.
Red Hat, for example, would certainly be able to make more money from consulting services arising from the diagnosis and repair of modified code than the per-incident charges, and if the customer took the time and trouble to modify the source, it is probably valuable enough to them to pay for a qualified consultant to figure out where they're going wrong. The customer is happy to pay and Red Hat is happy to charge. Everyone is happy, and that's the basis of a solid business model.Would Microsoft offer a version of IIS customized for a customer's unique requirements together with patches, architectural diagrams and documentation for less than $10,000 or $20,000 that allows the customer to extend the product to meet their future requirements? Hardly. But Red Hat could offer the same for Apache, and make a sizable profit in the process. <HINT>This is a business model unique to open source service providers that is largely, so far as I can tell, untapped.</HINT>
The concept of spending money on database consultants or software architects is old hat. What's the difference between charging for a highly qualified hacker with an intimate knowledge of sendmail, for example, to look at your code and charging for a highly qualified DBA to look at your schema? (Answer: None.)
-- My choice of computing platform is a symbol of my individuality and belief in personal freedom.
A users should have two options:
- he gets the program for free from your website and he will have to support himself with the newsgroup and other users. If het really wants support from you he will have to pay.
- he can buy the program from you. He will get a nice disk, a printed manual and a support contract for 6 months. This support contract applies of course only when they use the program as you provided it (no source code modifications). When a new release comes available you notice them so that they can upgrade. You should expect most customer questions to be simple, so have someone available for those basic questions and don't bother your star programmer.
Customers who really want source code modifications should pay you by the hour for support if they do it themselves. If they leave it to you you can either charge hours or make an offer for the project.
And look at some opensource companies how they do it. I think the most interesting is Lutris (maker of Enhydra). You could also check TheKompany. If you have done your homework you could even contact them for some advice.
Companies like Nusphere and AbriaSoft are probably less interesting because they support an existing product (in this case MySQL).
I mean, seriously, that's the only way open source is going to make the leap from being viewed as basically kid stuff to actually being accepted as a means of doing business. We have to have intelligent (read: overly committed, personable, friendly) coders to figure out how these changes might be made by someone who was willing and able. That doesn't mean, however, that you have to support every hack some kid makes to your code, but if ANOTHER coder used your stuff and wanted to implement something of his/her own, you should be able to foresee it. Of course, this only applies to a business model of OS programming, and it only applies if you WANT to provide support, but that's the only way to do it, as far as I see.
Emacs: for people who just never know when to
Me too... three times this week.
???
MadCow
I used to have a sig, but I set it free and it never came back.
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.
nice device, Duff.