Policy on package namespaces (internal and open source)?

[nicorikken]

We intend to publish packages of our open source projects to repositories like Maven Central. Especially in the Java world the namespaces in which packages reside is important. The most obvious namespace would be com.company.project like for instance Zalando does with org.zalando https://search.maven.org/search?q=g:org.zalando But at the moment already we have our internal packages that reside in this most obvious namespace.

Ideally I'd like to separate the namespaces of the internal and external versions of the packages. Because even though they might have the same version, they can originate from different build infrastructure and be slightly different. Also naming conflicts can introduce issues with internal package repository mirrors.

What are typical ways organizations deal with this issue of namespacing? I thought of some options myself:

• Use a sub-namespace for open source repositories: com.company.opensource.project
• Claim a different domain name for these open source projects: org.company.project (org instead of com) or com.companyopensource.project (I see some like this search for open source on Maven Central)
• Use different project names for external use com.company.newprojectname
• Update all internal namespaces to be explicitly internal local.company.project such that the public facing domain and namespace get cleared up for external usage.

I very much like to know what kind of policy you have in place for package namespacing and how you would deal with existing practices.

[mwichmann]

That's an interesting question. Java docs say it's up to you to resolve it. But if it's going to look like a real OSS project, it doesn't seem like you'd want to embed the company domain into the namespace identifier. You have a bit of an easier decision if you've created an "organization" for your open source projects (domain, website, other project infrastructure like chat channels, mailing lists, etc.) that is outside your company - then that should inform what naming to use. I can see where that's not always practical to have done, especially in the early stages...

[nicorikken]

Indeed, good point. We already have separate organisations and branding for projects that are intended to outgrow our own organization. My question was more directed to the smaller project for which a separate infrastructure would introduce quite some overhead.

[jlprat]

You could go with a tld.company.open.project format. Adding open in the middle would separate your proprietary namespace from the smaller open source projects one. As @mwichmann said, if you plan to give the project its own autonomy detached from your company, you might want to go away from using your company name in there.

[nicorikken]

Thanks, for my case this seems the best solution. I like the simple open rather than open-source with risk of typos. I marked it as the solution for my question.

[nicorikken]

Listed in the advice on Choosing your Coordinates the abbreviation oss is also used as a way to separate out the open source package in a separate group id, like: tld.company.oss.project. Just an alternative I wanted to mention here.

[dvberkel]

Naming conventions on Maven Central resolve around two important identifiers: groupId and artifactId. So differentiation on the project-level is facilitated through the artifactId.

So it seems to me that there is a choice to be made for the groupId. I like @jlprat suggestion of tld.company.open.