[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.
Disagree?
-Zack
More information about the consulting
mailing list