Marvin,

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 (duh²). 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.

—Theory

Theory,

Thanks for the comprehensive answer, it's very helpful.

Regarding subclassing... one of the items the first sponsor wanted was a specific kind of excerpt highlighter. What I did was open up the Highlighter API to make it more customizable, then wrote the custom subclass for them. The complexity is all within the library; they should be able to maintain the custom subclass themselves. IOW, there wasn't a "right" way to do things before, but there is now. Sounds like the kind of thing you've done with "translating" into a "generally useful" feature.

For cases where a "right" way can't be created... I dunno, I think that might not work so well. KinoSearch isn't as big as Bricolage, but it's still pretty big. Supporting hacked versions could get really complicated if the internals change. I'd lean towards declining the gig.

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com

Sounds like the kind of thing you've done with "translating" into a "generally useful" feature.

Yes, that's it exactly.

And yes, if it's too hacky, by all means decline the gig. Or better still, make recommendations for a correct implementation that you'd be willing to do, instead. Be sure to include arguments as to the greater maintainability and less of a headache for them if they decide to spend a bit more and do it the right way. Most companies will agree if the difference isn't excessive. As for those who don't, who needs them?

—Theory

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.

I've sometimes had, for odd reasons, customers who prefer to own the copyright of the code I write but are willing to licence it back to me under the GPL. So that's another option.

Oftentimes we charge a lower rate for this sort of thing, since they won't get any IP out of it.

Ditto. I've found this works best if you express it as a "discount" for the GPL code, rather than a premium for getting IP. YMMV.

Thanks, kwaping. The advantage of this approach is that it's closer to traditional contracting, which is probably more comfortable for both parties. You'd have to apply it on a case-by-case basis though. Some of the work people are asking me to do can only happen via making some fundamental changes to the library. For stuff like that, the preliminary work might turn out to be hackwork that might not survive updates.

--
Marvin Humphrey
Rectangular Research ― http://www.rectangular.com

Your clients will get the bleeding edge versions; while the public version will already be feature-ready for the bleeding edge patches. This way you can steam the people ready for using these development versions.

Seperate your good/opensource/happy code into one place. Seperate your bad/custom/closed/less-happy code into another place.

Your good code should always be a kernel. It's least buggy, easy to refactor and all that good stuff, reusable to all hell.

Your custom/ugly code should wrap your good code. As features are wanted in that kernel, and things are clean in the outer layer, it works its way in. But be warned, be careful about how they interact as the outter wrapper should not influence the good code on a continuous basis. It should come in sparks of brilliance, and reealuations.

Keep a repository of patches for the non-official modifications and keep the core code clean.