[consulting] Costs of forking

[Boris Mann]

On 8-Feb-06, at 11:41 PM, Zack Rosen wrote:

>> 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?

This is not a Drupal thing. This is a "how should you figure out what  
to charge clients" thing.

> 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 knew I phrased my initial comment wrong....you are NOT  
misrepresenting the costs...you are including the "real" costs of  
using an open source platform. Let's face it -- dev work is NOT  
billed on "it took me 8 hours to sit down and code". It is based on a  
combination of factors that *include* how long some number of  
developers actually sit at keyboards, but also things like margin,  
timeline for project, how much thought/architecture is required (do  
any of you break out "architect solution" as a separate line item?)  
etc. etc.

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

Absolutely...+1 for education. Have to be *very* careful about  
explaining that, e.g., payment != guaranteed inclusion in (for  
example) core.

--
Boris Mann
Vancouver 778-896-2747 San Francisco 415-367-3595
SKYPE borismann
http://www.bryght.com