in reply to (OT) Sponsoring open source

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 (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.

—Theory

Replies are listed 'Best First'.
Re^2: (OT) Sponsoring open source
by creamygoodness (Curate) on Jun 13, 2006 at 19:23 UTC

    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
[reply]

      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

[reply]
Re^2: (OT) Sponsoring open source
by adrianh (Chancellor) on Jun 14, 2006 at 08:21 UTC
    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.

[reply]

In Section Seekers of Perl Wisdom