|The stupid question is the question not asked|
Re: (OT) Sponsoring open sourceby Theory (Beadle)
|on Jun 13, 2006 at 17:50 UTC||Need Help??|
Congrats on the offers. That's great news. There's nothing better than getting paid to improve something you really care about.
Kineticode does some work like this on Bricolage. The way we structure it is to really do the research ahead of time, both to understand the customer's requirements and then translate them into a generally-useful Bricolage feature. Then we examine the code to come up with a general implementation plan, calculate approximately how long it will take, double that time (duh), and then multiply it by our hourly rate to come up with a project cost.
Then we send an contract to the customer in which we agree to do the project for the set price, and include an inemnification clause (duh2). It also states that the customer will not own the code, and that it will be contributed to the project under the same license as the project. Oftentimes we charge a lower rate for this sort of thing, since they won't get any IP out of it.
But the short answer here is that I try really hard to do the code right from the very beginning. Most customers respect this (they don't want it to break!), and are simply happy when, at the end, it does exactly what it needs it to do (even if it wasn't in the way they originally expected). We simply don't do the quick hacks unless the customer is willing to maintain a patch themselves. And no one has gone that route.
Now, in some respects, you have an advantage with KinoSearch. It seems like, if there isn't a <q>right</q> way to do something, like change the API, or if they just want something quick and dirty, then you can create a subclass and just have them use the subclass. You can even offer to maintain it for them (for a fee) in case something changes in KinoSearch that would cause it to break later.
But just to reiterate: I figure out what the customer wants, figure out how best to do it in Bricolage to improve it without sacrificing code quality or consitency, and then tell them what we're going to do and how much it will cost them. I don't even give them the option to do it quick and dirty unless they ask for it.
Works for us, anyway.