How to distinguish internal objectives between open source efforts and non-open source efforts which are directed at community building

[anajsana]

Question raised at TODO Slack by Dave Viner:

How do you distinguish your objectives internally between open source efforts and non-open source efforts which are directed at community building (e.g., 3rd party developers)?

I know not everyone has this challenge, but I'm curious to hear from those who do. To try to clarify, let's hypothesize that Company X has some open source projects which have wide adoption as well as some products that have public APIs. By nature, the product APIs are public, but the code powering those APIs is not open source. (Of course, demo apps/code calling the APIs is open source or otherwise freely available.)

Focusing on growing the community of developers leveraging open source is similar to growing the community of developers/products that leverage the product-APIs.

How do you distinguish objectives between these two? On the one hand, "growing adoption/usage in 3rd party developers" unites them. On the other hand, there is some inherent difference in my mind between open source software and calling a set of APIs.

[anajsana]

Dave McAllister replied:

I tend to agree that the two are not the same. Part of it is the fact that we don’t really have a great definition for the word “open” (I did that talk back in like 2011)

I think that it can use the word open to mean (definition from an OSTT EU some time back) ” Open refers to a process that generates trust, permitting positive interdependence” Then we can use it with either.
However, I do tend to split these into open source (interdependence derived from base code interactions) and Open APIs (interdependence derived from ecosystem or platform expansion)

I do think that trust is the key concept. As a developer, do I trust (or have insight into) your API expansion, contraction, Do I have to worry about that access suddenly changing or being removed?

For source, especially with the spate of relicensing (Elastic vs opensearch, or “source available”) I always have the option of forking and driving my own support. My trust requirements are there but different.
Anyway, this is a fascinating topic that I’d love to dig into deeper.

[anajsana]

@gyehuda replied:

It’s a good question. There’s one line that I’ll gently suggest might help clarify things. “Focusing on growing the community… is similar to growing…” The “is similar” is probably where you want to dig deeper. Specifically — in what ways are they not similar. I might be motivated to get an API key and use an API (rate limited? For a fee, etc.) because my business needs the service you provide. My motivation for engaging in your open source may differ.

When it comes to getting me hooked into your API, your devrel people will show me how using your API will help me deliver my project. But the open source community manager might take a very different approach to get committers and engagement.

So your outcomes differ too. You want me to use your API. I get that. I might pay, I might be invited to be in your ecosystem and get hooked into other services. Whereas with open source, it’s not enough to get more users. You probably want more than that.

The difference: APIs are a product, open source code is a project. You sell products to customers (or give them to users). You engage people in a project to help it evolve. I see these as being different. They may be on the same developer.companyname.com website. But they are different audiences completely.