Recent blog posts
Sites that link here
Costs of forking
A lot of full time Drupal/CS consultants I've been talking to here in Vancouver have been sharing concerns about how to meet the needs of their clients while still being able to contribute code they development back to the Drupal community. The general assumption is that most clients are oblivious to the mechanics of open-source communities and assume that they are paying simply for an engineer to develop new functionality and ignore all the time required to work with the Drupal community to make sure contributions and patches are accepted and merged back.
I think the simplest solution is to figure out a way to asses costs to forking code that can be communicated to customers upfront when contracts are negotiated.
How about this estimate?
- Costs to mantain your own forked module: 25 developer hours X $100 an hour X 2 times a year = $5,000 a year per module.
- Open-Source development resources lost: 5 hours per patch X $100 an hour = $500 per patch.
Using these estimates I would think that consultants should be able to justify adding in a line item to their contracts up front to cover their costs to contribute their code back to the community. Do you think this will work?
Comments
not sound
Wouldn't it be just as easy to make the clause say the equivalent of "the work I do may be released as FOSS". Then when you're developing, just make modules with the intention of committing it to Drupal CVS.
I say modules because I think forking core is almost always the wrong solution if you can manage to get the project done with modules. I forked some core modules like the forum and it's been nothing but a headache. I should have forked into a brand new module instead of trying to go back and sync core updates with my fork again. Unfortunately, I never expect if I have to modify something in core that any patch I make will be committed in a timely manner, or at all.
I don't think this is a full solution
Because then it is left to the contractor to gain community support for their contributions off the budget of the project they developed them for - even though it is in the best interests of the client for this to happen.
Time and dealines are invaluable
True, forking may not be an option. For most projects it is not smart anyway.
But you forget that nearly all projects have deadlines plannings and followups. In other words: they need to be live yesterday, if not the day before.
In that case, you simply cannot wait until some Drupal devel finds time to review a patch. Simply because that brings too much uncertainty. You do not know what you will bump against further down the road, when working with a not-to-your-project-committed bunch of developers.
If you have to deal with all the Drupal developers, all with their own agenda's, then you will find that branching is the only way to go. Simply because that is the only way that you can stick to your schedule and have the most insurance that your can get your project out in time.
Open source development, and the traditional project management do not go together. Its a pity, but a fact. You either need to adjust your project management (IMO that is the best route) and strip out stuff like deadlines and plannings. Or you need to stick to the traditional project management, and not be too involved in all the community matters of OSS (aka: fork and work in your own little corner).
Bèr
I think we can figure this out
IF we are able to educate clients to some of the mechanics of open-source communities.
Forking is not an option
Sometimes forking is not an option but a must have. Sometimes a patch won't be applied because it doesn't meet with the maintainer's idea or other habitual reason.