Commercial Support for Open Source Products? 80
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?
implement vs integrate (Score:1)
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
snort (Score:1)
Re:Maybe? (Score:1)
Re:easy answer: (Score:2)
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..
Re:Almost true; (Score:2)
Whats the deal? (Score:2)
Open Source Business Exchange (Score:3)
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 [mailto]. 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
Explaination: (Score:4)
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.
Re:Explaination: (Score:4)
is not all bad. People will have fun with it
and it will die away in time. What's the big
sporking deal?
The slashdot model is essentially flawed because
it's supposed to be an open and uncensored forum
but there are all these sporking moderators.
Say something unpopular in an open forum and
you get moderated back to sporking hell. Just
how uncensored is that?
Re:Almost true; (Score:2)
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!
Easy. (Score:3)
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.
Support for Commercial Open Source code. (Score:1)
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
Hey, you're here to make money, right? (Score:5)
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
Re:What the hell's going on around here? (Score:1)
Re:Maybe not, or, The Problem With Asking The Clie (Score:2)
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.
Re:Consider this support strategy... (Score:3)
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.
So Silly! (Score:2)
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.
--
The only way to really make sure... (Score:3)
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
Re:Working at our own OS product... (Score:1)
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.
Maybe? (Score:2)
Re:What the hell's going on around here? (Score:1)
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
Re:Maybe not, or, The Problem With Asking The Clie (Score:2)
Support the binary, not the source (Score:5)
"verifiably" is impossible, however (Score:2)
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 [slashdot.org].
Basically, the problem is client-side security. I fully agree with the rest of your thoughts, however.
Maybe not, or, The Problem With Asking The Client (Score:5)
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're free to choose (Score:3)
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.
Re:What the hell's going on around here? (Score:1)
Management Service Providers- for software (Score:1)
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 [mspassociation.org] website.
disclosure: I happen to work for a company that is part of the MSP organization.
Re:That has to be the simplest and most flexible (Score:1)
Modcrackdot - we could have geek contractors (Score:1)
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!
That has to be the simplest and most flexible (Score:2)
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)
Re:What the hell's going on around here? (Score:1)
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.
Re:What the hell's going on around here? (Score:2)
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
Re:Support the binary, not the source (Score:2)
Re:What the hell's going on around here? (Score:1)
Anybody actually know that this kind chain reaction can't happen?
Re:What the hell's going on around here? (Score:1)
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.
easy answer: (Score:4)
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.
Supply a binary. (Score:1)
Give them a pre-compield binary executable and specify that the contract is for that only.
Offtopic posts (Score:1)
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.
Re:Offtopic posts (Score:1)
If you're not wasted, the day is.
What the hell's going on around here? (Score:3)
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 [slashdot.org]? 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.
Re:What the hell's going on around here? (Score:1)
What kind of "support"? (Score:3)
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).
Re:What the hell's going on around here? (Score:1)
some products do (Score:2)
postgres has support
mod_perl you can even buy support for
im sure this is an industry waiting to boom
Re:What the hell's going on around here? (Score:1)
Simple! (Score:2)
What the hell indeed! (Score:1)
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 [geekizoid.com]. 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.
Hmm (Score:2)
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.
well... (Score:1)
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.
Re:Offtopic posts (Score:1)
Re:personal opinion (Score:2)
"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.
Re:personal opinion (Score:3)
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.
Almost true; (Score:2)
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! [bunnyhop.com]
There are limitations... (Score:2)
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! [bunnyhop.com]
Re:There are limitations... (Score:2)
CoA designs sales tracking software X.
CoB, a purchaser of said software X, has added a feature to it, so it's now X.1
CoC and CoD want said feature, and you can provide it in future versions thanks to CoB.
It's not fair to say CoA never spent a dime to develop, because without the initial investments and design of X, there would not be X.1
Are you, CoB, gonna be miffed that someone else sold X.1? Well, how about the fact that because X is Open Source, you didn't *have* to pay for X in the first place? It cost you nothing to use it, so why would you be bothered that someone else is using your software, X.1?
Let's say you purchase product X, and modify the source to become X.1; The value of the product to you is in how you use it to satisfy your need to do sales tracking. If X.1 does that for you, all your needs have been met. Sales of X.1 to other companies through CoA is irrelevant because that was written into the contract and also because CoA spent the money you paid them to give you X, X.1.1, and X.2, saving you a further 400 hours. Does it matter to you that X.1.1 was created at CoC, giving you features you didn't pay for, but get for free because you have the source? And because X and X.1 and X.1.1 was so beneficial to you, you upgrade to X.2 for the support and service contracts.
What motivation would you have to make significant modifications to a program? How about knowing that you need said modifications to get your job done? Why does it matter that the vendor sells the mod in a future release? If that is an issue, create a contract in which features and enhancements to product X because of CoB give you a kickback; otherwise, live with the fact that without X you would have to roll your own, and instead of spending 200 hours of development, you would have to spend 1200 hours of development.
It's perfectly reasonable to ask for or look for profit sharing, as it was your work. The point is that you still *save* money by using X over rolling your own, and you still make more money using X.1 than by using X, and that there is a profit increase by licensing the codebase instead of rolling your own.
If the contract that CoA demands is no kickbacks, you can choose not to do business with them; on the other hand, since the source is free, by doing business with CoA, you get access to all the development on X that CoC, CoD, and CoA invest into the code, saving you previous development and resources.
It's the choice of whether the model saves you more money, or whether rolling your own does. It's a rational choice.
Geek dating! [bunnyhop.com]
Re:This sounds about right (Score:2)
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! [bunnyhop.com]
More precise response: (Score:3)
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! [bunnyhop.com]
This sounds about right (Score:4)
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! [bunnyhop.com]
Working at our own OS product... (Score:5)
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! [bunnyhop.com]
the answer is simple (Score:3)
(end comment) */ }
Re:the answer is simple (Score:1)
you beat me to the pshicic friends network
Re:personal opinion (Score:1)
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.
Re:personal opinion (Score:1)
personal opinion (Score:2)
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?
The Simple Solution (Score:1)
---
Consider this support strategy... (Score:4)
-- CTH
---
The answer is so damn easy! Damn! (Score:1)
-
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.)
start with newsgroup... (Score:1)
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).
Re:the answer is simple (Score:2)
Installation support should be on an incident basis and should require that the customer obtain their software from you.
Mission-critical support should require the client get the software from you and sign some contracts involving what they can or can't do to the source if they want that support offering. Could be billed per incident, hour, or year.
Lastly, you could offer developer consulting, where you help people add features to your software. This would have to billed hourly.
In general if you are handling altered code, it needs to be billed hourly and on a best-effort basis. Otherwise other options can be used. But remember, support and consulting will likely be how you can make your money. Find out what people need and provide it at a profit.
Well, you could ask... (Score:2)
Mod points galore... (Score:1)
Me too... three times this week.
???
MadCow
Same as bug tracking on Open Source Projects (Score:3)
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.
bug tracing (Score:3)
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.
OT: Always wanted to say... (Score:1)
Re:The only way to really make sure... (Score:1)
Re:Almost true; (Score:1)
Re:There are limitations... (Score:1)
Now, pretend I'm the client who wrote the mods. Aren't I going to be a little miffed that my sales software vendor took my 200 hours of development and used it to increase their profit margin, leaving me with exactly nothing in the way of compensation for the work I did, without which they'd be making less money?
As a client, what motivation would there be to make significant modifications to a program, knowing that the vendor will sell the mods in a future release, profiting from my development expense?
If I were the client in this scenario I would look for some offer of profit sharing, or some other way the vendor is willing to compensate clients who contribute a major new feature to the program. Don't forget, while competition is good for consumers, companies generally don't view it as an added benefit.
Re:There are limitations... (Score:1)
Re:Almost true; (Score:2)
What's to stop you from taking their modifications, rolling them into your binary, and selling them to your customer base? You get all the $$$ with no development costs and the other company only gets credit in the README and the open source version.
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?