[consulting] Costs of forking

[Bèr Kessels]

Op donderdag 09 februari 2006 10:50, schreef Boris Mann:
> 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.

In my client environment, they really don't give a **** about forking, 
maintaining patches, or being part of the club. they Just Want A Site. 
Finished by tomorrow, but preferably yesterday.

Starting about forks, hacks, maintainance is not a good thing, so I learned. 
Talking about costs is neither a good thing. 
me: I have two options for you on how to get that little message appearing 
there, to be the way you want it: 
 1) I develop this specifically for you, which means that you cannot benefit 
from my maintainance and upgrade offers. 
 2) I develop this for the syste, but that means that this thing can delay our 
project rather much, and we still have no certainty it goes in.
she: I don't care, as long as you stay within the budget and the site is 
finished yesterday, its fine.

Most of the times when you start about "community development" or the 
"benefits of OSS development" the eyes of your client or CEO will glaze and 
once you finished go like:
 "but will my project be finished in time, within the budget?" "yes", 
"allright, then you work this out in the OSS way, if you think that is best". 
In other words:  make sure that people can see the benefit directly, in CEO 
language (planning, costs, overhead etc) rather then trying to educate about 
forks, patches, maintainance, upgrades, security patches, community reviews 
etcetc.

I see only costs mentioned here, we should focus on the planning part too. For 
that is still my main reason to branch quite often. The overhead part needs 
some light too, IMO. Because we say that maintaining a fork requires hours, 
but forget to mention that a core patch, requires a lot of hours too, just 
that these hours are needed in a different phase of development. (maintaining 
and pimping pathces needs hours at the time that one can least miss these 
hours: during development, while maintaining your branch becomes a *** if you 
run into security or upgrade issues.) And last, a fork requires specific 
developers, while a none-forked project can call in any Drupal developer. 

Bèr