Unintended opensource forks

When an organization wants to use open-source software, a common practice is to take a release and start working with it, initially testing out on upstream's supported platforms and tested configurations. Team learns about the project, its design and inner workings. Up until here it's all fine. Next step is to add a new feature, or port it to work on the company designed hardware. Team starts to make changes.

That's the fork in the road !!

The moment when change is committed to local repository without upstream being involved or engaged you have created a fork of upstream project, perhaps an unintended one. It also means that you are now competing with the changes of other developers in that community because they may make conflicting changes in same area touched by your teams, or re-architect, do major code reorganization, change APIs ...

You have two choices

Create a hard fork which never merges upstream, the cost of maintaining it increases exponentially with time

or

Engage with project upstream, make a case for the changes you want to do, negotiate and listen to community feedback on your proposal. While it may seem moving slowly, your changes experiencing more vetting, sometimes negative feedback etc. may make you conclude it as waste of time and resort to option 1, but in long run the payback of this time spent doing it with upstream results in lower cost, improved feature velocity and above all happy developers and happy customers

Watch out for these invisible forks fervently, before you walk down them too far.