loading...
Cover image for How Do You Open Source A Project?

How Do You Open Source A Project?

forstmeier profile image John Forstmeier Updated on ・1 min read

I have a question to project managers out there that stems from interest in a project that I'm currently brainstorming.

Given the scenario below:

  • You are in charge of a close source piece of software
  • You have been tasked with open sourcing parts of the codebase
  • You will be transitioning the codebase to an "open core" model

How would you go about completing this task?

Now, this is a really big, open-ended question so perhaps I can simplify the scope somewhat:

Given the above scenario, what would be the first steps you would take or questions you would ask towards implementing your solution?

Discussion

markdown guide
 

If the parts you're looking at opening up aren't independent modules yet, the first step is extricating the code and infrastructure. Give them their own source repositories and build processes, and store the output in a private artifact repository like Artifactory so your other build processes can source them almost as if they're downloading from a public registry. (Re)write the documentation with the broader public audience in mind. Include examples since most people won't be able to look at your codebase for reference. The earlier your organization starts treating it as an "external" dependency, the easier throwing the switch to open it up will be.

 

What are some telltale clues that would lead you to determine whether or not code and infrastructure were tightly coupled?

 

By "infrastructure" I mean build processes, package management, and so on. It's naturally tied to the code; the problem is when the code you want to open is mixed in with the code you don't. That's usually pretty obvious.

Gotcha. And from there you would be inclined to review what has been separated from infrastructure/etc for modules to open source (assuming something like "open core" was being followed)?

Your infrastructure is very nearly irrelevant in the grand scheme of things. That tooling is just how you deliver for your own organization, based on your organization's context and needs. It's the launch pad and rocket boosters; you're trying to open up the space shuttle. I've got my own launch pad and so on already.

That said, if you've already factored some non-trade-secret stuff out into its own module that you deliver separately and think of as a dependency in the parts you don't want to open, yes, it's a natural candidate for opening.

 

Spend two months on writing docs and unit tests - that's what I did, for the most part.

 

Were you open sourcing the entire project or segments of it?

 

It’s usually a framework or library that you used to develop your project.