We have an internal project with, for instance, an authentication backend. The code for this backend is purely custom made for the needs of our company. However, we are in the process of releasing our project as an opensource project. For that purpose, we created a new authentication backend, that use standard and open software. So we can publicly release with the new backend and keep the other for us.
Now the issue:
We want to have the public git repository without the custom internal code. How to separate public/private code without risking to end up with two projects drifting from each other ?
Many options appears to us with some pro and con, so we came here to see if anyone encounter this situation already or have any suggestion ?
Unilaterally ensuring anything about the future course of an open-source project is a futile effort. Any controls you might impose would just be circumvented by the community (e.g. by forking) if they turned out to limit a direction that people otherwise want to take.
So at some level, maintaining consistency means you have to internally have a commitment to keep your internal version in line with wherever the winds blow the OSS version. (Such a commitment needn't be absolute... just, if the public changes go beyond what you're willing to keep up with, at that point the projects will diverge.)
That said, you can do things that will probably discourage changes that cause the public and private versions to diverge. To me that means two things:
1) You want to discourage changes to the interface between the auth back-end and the main project, so that it remains possible to swap between the public and private auth back-end.
Though it seems a bit thin, one step would be to publish the auth back-end separately from the main project. Each could have its own git repo, and assuming you use a dependency manager in your build tooling the back-end could be listed as a dependency of the main project. Then people working on modifications to the main project might not even download the source code for the auth back-end; and in any case, to change the interface between the two they'd have to make coordinated changes to two public projects. It makes it less likely that it would happen casually.
2) You also want to make sure that whatever changes do happen, you can pass them back and forth between the public version of the project and your local version.
This again is helped by keeping one repo for "what's the same" (the main project) and separate repos (public and private) for "what's different" (the auth back-ends).