Ask HN: How to manage internal forks of OSS projects?

2 pointsglawre4y ago2 comments

Hi,

My company are using an open source software project heavily. We’re a large org and we’ve had to hack the code base to fix up bugs, extend functionality and add new features.

Our internal fork breaks down into three categories:

1. The base software.

2. Generic improvements to the software that could be used by other people.

3. Specific extensions to the software that are only value to our own organisation (e.g integration with our legacy systems, our change management systems)

I’m encouraging our team to contribute the generic improvements (item 2) back to the upstream to minimise any maintenance overhead, and this is working well.

However for Item 3, I’m finding it particularly difficult to confidently pull in upstream changes where we have heavily modified the original implementation. Ideally I’d like to be able to pull in upstream changes quickly, easily and safely.

Does anyone have any suggestions, references or patterns to consider for this type of software project?

The software is primarily Python, with some Java for good measure.

2 comments

jka4y ago

I'm not sure that any of these ideas will be news to you, but a few suggestions:

- Add test coverage for your customizations, so that after you pull upstream changes, you can confirm that your software still works (or at least runs)

- Relocate and/or rewrite the custom code within your repository so that you are less likely to encounter merge conflicts when retrieving upstream changes

- If possible, fetch upstream changes on a regular basis so that you detect upcoming conflicts early

- If possible, petition the upstream project to add support for plugin modules, so that you could develop your own customizations in isolation (albeit still with some API-level dependencies on upstream)

Are your customizations definitely specific to your own company? (a gold standard could be to publish your own software as FOSS and attempt to build a supportive community)

theamk4y ago

Keeping private fork requires non-trivial design skills. In the ideal case, you'd add hooks as part of public improvements (item 2), and use only those hooks in your private changes. If you add appropriate tests to public project, this will increase the chances of your hooks staying unbroken.

j / k navigate · click thread line to collapse