zipkin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Cole <>
Subject Re: pre-existing projects and the ASF
Date Mon, 25 Feb 2019 01:04:20 GMT
Thanks, Shane, for the background.

Waving at mentors as well. I will discuss 2 things.. add ons and decoupled

### Commercial add ons

Concretely, one example here is Google cloud storage integration for their
commercial product Stackdriver (a SaaS).

More concretely, there is a lot of product risk due to drifting APIs and it
isnt fair to burden the ASF community in to do formal release process on
unstable commercial add ons.

There is no party I am aware of selling anything we produce in our orgs btw.

### Other language libraries

We have other languages like ruby and go for sdks. While in ideal terms
there is 100pct coverage for all languages doing the 72hr vote thing, it is
unreasonable to expect all forms of volunteering to be forced into the same
place. We want people to want to be here not forced to. Trying to force
might remove such integrations from existing at all. Moreover, it is
routine for sdks for many apache projects to not all be apache controlled.
We need a concrete way to discuss libraries that exist all over many
projects in a non ultimatum way.

Let's start concretely with zipkin-ruby and zipkin-go. Yes they have the
word zipkin in them, but take any large brand and we will find many many
ecosystem utilities not strictly controlled by that brand.

At least what I am aiming for is to have guidance based on the reality of
today, which is how to treat contribution modules made by volunteers. If
the word zipkin is too heated replace with Kafka or Cassandra.

We need to figure out how to work with our ecosystem even those not
migrating to ASF yet.. especially in a way that doesnt paint ASF as a
policing against volunteers... rather one who wants to be the place
volunteers prefer to be a part of.


On Sun, Feb 24, 2019, 12:13 AM Shane Curcuru <> wrote:

> On 2019/02/14 11:05:22, Adrian Cole <> wrote:
> ...snip...
> > That in mind, I wanted to pre-clear what should be implicit, which is
> that
> > existing zipkin projects in our orgs are allowed to remain in our org and
> > be released as usual after some repositories are moved to the ASF.
> ...snip...
> That depends - what does that mean, specifically?
> In general, there are two concerns that need to be met for TLPs:
> 1- Apache TLPs need to be masters of their own fate, and provide a
> complete product that does some sort of useful functionality on it's
> own, without relying on outside modules (in general; we rely on OS's,
> commonly installed things in target environments, docker runners, etc.)
> The rationale and basics to this are here:
> So, as long as the future Apache Zipkin TLP can be built and do useful
> things by only starting with repos, whatever other people
> want to do with their related *code* is just fine.
> 2- Branding.  When you say "existing zipkin projects in our orgs", I
> don't know enough about what you mean to know how it affects external
> parties and the larger world.
> -- If SomeCompany wants to continue to make publicly available a "Zipkin
> Accelerator Package" based on those repos, then no: that's a violation
> of Apache trademarks and conflicts with "Apache Zipkin"
> -- If OtherCompany has a bunch of internal Zipkin-Acceleration-Deploy
> modules that they use for their own purposes, that's just fine.
> Trademarks (generally) only matter when they're publicly visible outside
> of an organization.
> If it's something else, we need to know what the general public will see
> about those repos to know how to advise.
> Does that make sense?  Note I'm not on zipkin lists, just reading the
> archives.  Figuring out more specifically what the question is with your
> mentors first would be great; if that doesn't get a complete answer,
> then ask the Brand Management team.
> --
> - Shane
>   ASF Member
>   The Apache Software Foundation
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message