Building a process to decide if a project should be open sourced

[anajsana]

Question raised via TODO slack channel:

Hi, everyone!

At my company, we have a documented process by which we decide if a project should be open sourced, but I am having trouble understanding whether the process is too bureaucratic or too loose, or if we’re missing anything. On paper, it looks a lot like other companies’ processes, but I am not able to benchmark it against them on a more practical level.

Also, we tend to be inconsistent with respect to the team initiating the process - sometimes the Engineering team knows with certainty that they want to open source a project (i.e. publish under an open source license), other times they hint at open sourcing, but Legal gives the final push towards the open source publication (if it matches with the Engineering intention, of course). The teams always make the decision together, but I feel that the process could be tighter; I’m not sure how to improve it without making it too burdensome for everyone.

I am currently in the Legal team, but transitioning towards a Program Manager role (with focus on open source), and I’m taking a goal for myself to nail down this process.

If anyone has any advice on the above, I’d be grateful for a comment or a 30 min. conversation sometime.

Thank you!

[anajsana]

@jlprat replied:

I'd like to say that Open Sourcing a project is not just making a project public and adding a license to it. Open Source projects should be about community and be open for shared governance, without those 2 aspects, in my opinion, projects are not really Open Source but simply made public

[anajsana]

CSV replied:

To add to Josep's line of thought, what are the goals/expectations from the teams/company when open-sourcing any project? Few thoughts...

we have a documented process

Already better than most teams/companies

tend to be inconsistent with respect to the team initiating the process

Sounds fine as long as the expectations are documented and workflow supports anyone to kickstart the process

but I feel that the process could be tighter

Can you clarify what you mean by tighter? Are you looking for shorter turnaround times? Faster reviews/feedback? Something else?

[anajsana]

@jlprat replied:

At Aiven we categorize public projects into 3 types:

• Forks: they are what you would expect, forks of upstream projects with some change not (yet) merged
• OpenSource Projects: projects with proper license, with community involvement, and willingness on our side to share its governance
• Give Trust, Develop in the Open: those are public because we want those to be audited but there is no possibility (or maybe intention) to have a shared governance

I would encourage to define general guidelines on what and why we should open source projects, so both Legal and Engineering teams can have fruitful discussions starting from a common starting point.

Our process to open source a project needs an explanation on why this project should be open sourced: what are the benefits for the community (not us, but the community). We previously agreed with legal the type of licenses we can/want to use.

You might want to also look at https://github.com/todogroup/outbound-oss/blob/main/content/03-starting-oss-projects.md which is still WIP

[anajsana]

Valentina Ditoiu replied:

Thank you! I can tell that strategically you are for sure more advanced than we are. We haven’t had a real chance to think about what happens with the project after disclosure; I think I agree with you that without governance it’s just disclosure.

@ CVS I guess that by a tighter process I mean that we should have an open source strategy/roadmap in place to which Product and Engineering teams can refer when deciding whether to publish a project. Currently, Product Managers and Engineers seek to open source smaller projects that would enable the adoption of their parent projects; for example, we may publish templates for certain connectors (to be used in association with our core products). We are very cautious to not publish too much (also for IP/legal reasons), but I fear that this is an obstacle in development. To avoid having Engineering and Legal asking one another if a project should be published, I’d love for the teams to look at an open source product roadmap and say “yep, it fits, let’s publish”.
@jlprat Thank you for sharing those categories, super helpful! We also ask for justification as to open sourcing a project, but my naive question is… what is the threshold to say that the justification is sufficient? Who holds the bar?

Thank you for the encouragement, trying not to panic.

[anajsana]

@tsteenbe replied:

@ Valentina Ditoiu At my company we have 3 categories of company FOSS projects: forks (to facilitate contributing to upstream projects), vendor on-ramp (to make it easier for customers to use our products) and community (add value to the community, pursue of common goal)

[jlprat]

We try to ask ourselves these questions:
Will anybody care about this project? Or is it only us?
On the IP area. Does this project contain anything in our core? If yes, we need a deeper discussion including founders to see if it makes sense or not.
There might be other related questions depending on the project as well

Who holds the bar?

Mostly the OSPO team but for the Senior Management in our Product Department has a bureaucratic sign off, in case we missed something strategic

[jlprat]

@tsteenbe replied:

I done several sessions with product manager and engineering to determine an FOSS strategy - a key question is always “what our secret sauce”. Most find answer such a question over the years the method i just the most is to play devils advocate - I am the CEO we going to open source everything now tell me what we shouldn't open. Using open by default triggers in my experience a different discussion then what should we open-source

[ShaneCurcuru]

Great feedback - especially having a normalized "what is the end goal?" that includes at least these levels: throw it over the wall FOSS, we hope a community might form FOSS, and we will actively work to help build a community and allow them governance spots FOSS.

Some other key factors to ensure are in your roadmap:

• Do you have the right final deision maker inside your company? Engineers vs. product management vs. legal often come up with very different answers. Sometimes, they're the right answers for your company. Sometimes, they are the right answers for one team, but not for the company. Really understanding the long-term goal and value at a strategic level is useful - but only someone from your company can decide which team has the best perspective.

Engineers - yay open source! (For good and bad reasons)
Product management - how does this increase ROI?
Legal - OMG, the liability, we're giving away IP!

It sounds like your company is being pretty smart about balancing these "default" behaviors, which is good.

• Specific scope of the technology/project being open sourced. This matters internally - how does opening up that specific set of bits affect your corporate making money strategy? It also matters externally: is this project useful enough on it's own to enough other organizations or communities for them to want to participate?

• Amount of effort your company will put in short term into ensuring the project is documented with it's expectations. This doesn't matter if you're just thowing over the wall, but if you ever want a community to help build it in the future, it really matters. This is also a capacity planning question: will management really give the engineers / tech writers enough time in short-term to make the project self-explanatory, and also write good CONTRIBUTING docs so potential contributors know what to expect?

Good luck!

[ValentinaDitoiu]

As I read through your answers, it becomes obvious that creating the categories you speak of requires a thought process that we've never had in the company, on a practical and strategic level: "what happens to the project after it's published?" Somehow I thought that all disclosed projects will have a life of their own, and increase the ROI (never went in to investigate how exactly), and attract contributors (although we don't make particular efforts to promote the projects), and remain relevant (although we may not put enough effort into maintaining them).
Clearly, others have figured out that that is not the case by default and unless you purposefully create a path for a project, simply publishing it may not be very useful in the end - neither for customers, nor for the company. Creating goals will act as internal strategic references, helping teams decide if and how they should disclose and maintain a project.
I don't mean for the discussion to end, but if it does, I really appreciate all of your responses; I have some work on my hands. Thank you!

[ShaneCurcuru]

It's all about setting expectations. Simply throwing it over the wall - into a public GitHub repo with an open source license - is still a positive step. Even if you don't plan on running it as an open project (to new contributors - either code or governance), it still might be useful for someone else to fork and use for themselves.

But setting the expectation is the critical step: if you're just throwing it over the wall, make that clear in README or CONTRIBUTING docs. If you're hoping in the future to turn it into a potential community-centric project, but aren't ready yet, mention that too in the brief roadmap.

[caniszczyk]

A simple reminder that there is an older guide for this thought process here: https://todogroup.org/guides/starting/