[consulting] Costs of forking

Zack Rosen zack at civicspacelabs.org
Thu Feb 9 07:41:46 UTC 2006

> I just don't get it....structure your contracts so you include this  
> as part of your pricing, but make it invisible to the customer. ie.  
> -- your internal estimate is 50 hours for a module, add 20% for  
> patch/community interaction time, and show external estimate of 60  
> hours.
> You *could* make it very transparent as Zack has suggested, but I  
> suspect that this would increase the sales cycle and lead down the  
> road of lots more questions.

Understood that adding it to the total and not letting the customers  
know is the easiest way to do this.  The problem is the vast majority  
of consulting firms don't do it - they simply don't bill for the  
community work and then their efforts to contribute back are  
haphazard and unpaid which results in very little code share between  
the consulting firms and Drupal community over all.   As firms get  
more established and learn the ropes of Drupal they learn how to ask  
for more money and also realize that getting code back and  
contributing saves time / money over the long haul --- but why does  
every firm have to learn that mistake on their own and waste time &  
resources in the process?

A savvy customer _should_ realize that if they hire a firm to extend  
Drupal and the consultant forks their code they will pay $$ in the  
long haul to fix that mistake and therefor it makes a lot more sense  
to do open-source development "right" from the beginning, i.e. not  
fork.  Why must we assume that customers will never understand  the  
least about open-source development process and there for we should  
misrepresent the costs associated with development in order to get  
away with doing the job "the right way"?

I think the long term answer is to do start doing a little bit of  
customer education about open-source investment - teach the market  
the true costs of open-source development and services.  Can you  
imagine what it would be like if one of the deciding factors for many  
customers in comparing bids was the consultants ability/efficiency in  
contributing code back to Drupal?  I think that is a very worthy goal  
and really not that far off.



More information about the consulting mailing list