Maintain open and closed source software in the same repo

Hi all,

I am working on some software where there is an open source part and a closed source one.

The two parts have an interface that is very similar, but the implementation is quite different.

Each part must reside in a different file, so that it is easy and manageable to use git and avoid to check in closed code in the public repos.

The closed source part, as well the open source one, will need to interact with the rest of the project which is completely open source.

Is there some quick techniques that I am not aware?
Ideally I would like to have two files that do the same thing and switch between them using the compile level flags.


You could use features in cargo. Then depending on the feature you have selected, it will grab different dependencies. Then configure your private dependency using a git url. See the instructions further up the linked page for details on that. With a combination of that and maybe a few cfg attributes it should be simple to do if they use the same API.


I though about this, but the differences are really small and sparse in the code-base.

We are talking of maybe 1kLOC, create a new crate for this seems quite an overkill... Other than making the code too sparse...

1 Like

The code-size is not of concern. Since your license is different, you MUST have some kind of interface at the boundary.
People generally expect an entire crate/library/repo to be under the same license, so anything less than a crate would confuse them.

Confused people are likely to accidentally publish the closed source part along with the open part. Depending on how closed this is, this may mean anything from lost revenue to million dollar lawsuits...

I would also recommend learning about git submodules. This allows you to keep a subfolder of a repository as it's own, independent, separate repo.


We are talking of maybe 1kLOC, create a new crate for this seems quite an overkill

Yeah, I know what you mean. I used to feel that way. But small crates that have a very limited scope are common in rust. I've recently embraced it to try it out and it actually works pretty well. In your case I think it makes sense. Crates are a natural way to divide code, without separate crates I'm not sure how you would keep the private and public code separated.

Also, the crate is the unit of compilation in rust. So using many smaller crates can help with compile times during the development process.


I've published a crate with 4 lines of code total. Don't worry about it.

1 Like

@kornel, @juleskers, @ryan,

Thanks you all guys :slight_smile:

Since you all suggest the way of separated crates I am going to try that way :slight_smile:


What was it 4 lines for? Just curious :slight_smile:

1 Like