[consulting] Costs of forking
ber at webschuur.com
Thu Feb 9 12:49:11 UTC 2006
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
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.
More information about the consulting