Every month, new projects are submitted to the CNCF Sandbox in hopes of having their project join the CNCF. But, there’s a bunch of things that often escape the attention of companies and project maintainers when they submit their projects. It’s all in the fine print but, how often do we read that and realize what it means. With that in mind, let’s take a look at some things worth knowing and realizing before submitting any new project to the CNCF.
Give Up The Name
When projects join the CNCF, the project name is transferred to the Linux Foundation (the parent organization for the CNCF). Once this happens, the name usage falls under the Linux Foundation trademark policy.
You’ll notice this is a trademark policy and you generally need to protect trademarks in order to keep them. That’s why companies like Kleenex have campaigns and lawyers doing work that just protects the name. And why companies like Velcro make videos like this:
How does this apply to CNCF projects, you might wonder? If you have a project named Foo and someday want a Foo Enterprise version from your company, you’re out of luck. Or, maybe you just want a product name that matches the project name. You’re out of luck there, too. There are many name combinations like this you simply can’t use. The policy has examples of what you can and can’t do.
Operate In Public
When projects start out in companies, they are often run in private company meetings and organized around the company. This makes complete sense and it is a work product of a company. And, when it joins the CNCF this will need to change.
CNCF projects are expected to run in a transparent manner and there are requirements around people from multiple organizations being maintainers. To pull this off, the maintainers will need full access to everything which means it can’t be internal to one organization.
This doesn’t need to happen before a project joins the CNCF. But, once it’s in the change should happen. It will take time and everyone realizes that.
And what if this doesn’t happen? There are maturity levels in the CNCF that can’t be reached and if it comes to the attention of the CNCF, the Technical Oversight Committee might step in. If it comes to that you definitely want to work well with them.
Plan For Multi-Vendor
Have a project that supports just one of the major cloud providers (e.g., just AWS)? That may work great for your use cases or business but once it’s in the CNCF you’ll need more options in your project and roadmap.
The CNCF has members who are various competing vendors and the projects can’t play favoritism to a single member. This means that once a project joins the CNCF it will need to expand beyond ties to a single vendor.
Telemetry
Many projects collect telemetry and there can be useful reasons for it. For example, detecting which features end-users really use. If a project has telemetry, there are two things it’s going to need to do when joining the CNCF:
- Make sure the project adheres to the Linux Foundation telemetry policy.
- Any telemetry data needs to be managed/owned by the project and not a single vendor (like the one that created the project).
Policies like this shouldn’t be surprising. The CNCF/LF needs to make sure relevant laws are complied with and it’s the legally responsible organization for doing that.
Conclusion
I’ve maintained or contributed to numerous CNCF projects. I’m not looking to dissuade anyone from submitting a project. Instead, I think it’s better to go in with an awareness of what it means being in the CNCF. This can save you from some pain and frustration later.