Is there good material out there regarding maintaining internal forks of open source projects? #553
Replies: 2 comments 2 replies
-
|
This is probably nothing to the degree of best practices you're looking for, but Google Open Source has an imho rather comprehensive documentation on how they handle third-party code in their monorepo including descriptions about responsibilities and some mentions about tooling they have internally. This might give you some initial and helpful insights into how this could be handled. |
Beta Was this translation helpful? Give feedback.
-
|
@dellagustin-sap — worth checking out the |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello everyone,
One common situation that is faced by companies is the maintenance of internal forks of open source projects.
Of course, this is something that we try to avoid, as we usually promote that people try as much as possible to contribute to existing projects, instead of forking, but in some cases, it can't be avoided.
When we do fork then, some challenges and questions arise:
It would also be interesting to have material on the archetypes of forks, e.g., internal forks used just to have more control over the release lifecycle, but they are kept as much as possible in sync with the original, vs hard forks that have completely branched out from the original at a certain point.
If you have material, on this topic, please share, it would be interesting to build up on collective knowledge about this topic.
Best Regards.
Beta Was this translation helpful? Give feedback.
All reactions