You are a manager of a technology company, and your engineers love Git in general, but Git is not a perfect fit to your organization. Perhaps some work-flow elements your people are used to are not supported nicely by today's Git. Perhaps some class of assets you want to keep track of are not supported well by today's Git.
You are wealthy enough to pay for a developer or two to identify, design and implement necessary changes to Git, but you are not wealthy enough fork Git to maintain such a change yourself forever while the upstream Open Source community continues to improve Git.
What can you do?
Of course, if the changes you initially develop are good enough, they may be merged to the upstream and then you do not have to worry about maintaining your fork yourself. But how would you ensure that the quality of your changes is good enough for upstreaming? Perhaps withhold the payment to your consultants until the changes hit the upstream?
I do not think this is necessarily limited to Git, but applies equally to any useful and active Open Source project.
1 comment:
Perhaps withhold the payment to your consultants until the changes hit the upstream?
Very nearly that. Don't hire a consultant to "add feature X to a fork of git" hire a consultant to "add feature X to the mainline git code". That consultant could be someone who already works on the mainline code, or it could be someone who merely thinks they can do a good enough job on feature X, and that feature X is widely useful enough that someone that already works on git will accept it as a change. Or in the extreme case the consultant doesn't even do any doe work, they just convince an existing maintainer to do the work.
Just make sure the consultant knows the work isn't to get the feature to you, it is to get the feature to you via the official release distribution.
Post a Comment