[consulting] Costs of forking

JasonN imjasonn at gmail.com
Mon Feb 13 04:46:03 UTC 2006

I don't think you can easily valuate the time or money costs to
forking projects.  I realize the method of module management that
Drupal has assumed makes contributing back to the hive difficult at
times.  However, using any open source community shares similar
challenges.  But, it's not necessarily something you can easily
valuate, let alone explain to the client.

That said...

> A lot of full time Drupal/CS consultants I've been talking to here in
> Vancouver have been sharing concerns about how to meet the needs of
> their clients while still being able to contribute code they
> development back to the Drupal community. The general assumption is
> that most clients are oblivious to the mechanics of open-source
> communities and assume that they are paying simply for an engineer to
> develop new functionality and ignore all the time required to work
> with the Drupal community to make sure contributions and patches are
> accepted and merged back.

Most big software firms charge a "library" fee to their clients for
code that will or has been reused.  In the case of open source based
projects, you are basically giving your client thousands of free labor
hours when you use the community.  There is more quality assurance
there than in most big retail software shops.  And, you don't have to
charge them for that QA work or the free bug fixes.

Don't you pose two questions here:
1) How do we explain or justify our invoice?
2) How do we qualify the value of our business model to our client?

> I think the simplest solution is to figure out a way to asses costs
> to forking code that can be communicated to customers upfront when
> contracts are negotiated.

I agree, but think maybe you are framing the suggestion different than
it could be.  When you pitch the client a model, or a project
methodology, you are competing in the open market where the
alternative is that each and every line of code you contribute to
their site is original retail, closed source, closed ownership code. 
There's NO WAY you offer a more expensive solution with that model
than the guy charging retail for a one-time only development, or
single source retail.  Your TCO is always going to be much less.

>     1. Costs to mantain your own forked module: 25 developer hours X
> $100 an hour X 2 times a year = $5,000 a year per module.
>     2. Open-Source development resources lost: 5 hours per patch X
> $100 an hour = $500 per patch.
> Using these estimates consultants can justify adding in a line item
> to cover their costs to contribute their code back to the community.

I doubt the big corporate software shop justifies their library cost
beyond saying "This is the cost of gaining previous work product.  For
example, the library cost associated with the big corporate software
job buys access to hundreds of previously coded functions and code
libraries.  To write all this from scratch would cost much, much more.

I think valuating the time like you describe relies on selling the
concept of the whole open source community as a [preferred] business
model.  You do that when you charge significantly less than the 'gun
for hire' closed source shop.  However, a simple "You're paying for
access to thousands of lines of code and software QA without the
hourly billing," pretty much sums it up for the average client.


Jason A. Nunnelley

More information about the consulting mailing list