1 of 9

Project: Zipkin (Adrian Cole)

1

2 of 9

Zipkin’s UI looks like this

2

3 of 9

Zipkin architecture looks like this!

3

4 of 9

Zipkin’s history in short

2011-12: Zipkin developed at Twitter

2012: Zipkin open sourced

2015: Zipkin -> OpenZipkin

2015-16: OpenZipkin boom

In the last year, we’ve opened dozens of repos and performed hundreds of releases.

4

5 of 9

A selection of the Zipkin ecosystem

Zipkin contributions come from many types of companies including Twitter, Uber, Presi, Sound Cloud, Dealer.com, Salesforce, Pivotal, LINE.me, Coursera, Yelp, Jive, Buoyant and Finn.no.

Zipkin libraries exist for most languages and popular libraries like Spring Boot and go-kit.

5

6 of 9

Zipkin’s community flows like this

6

OpenZipkin GitHub Org

3rd party tracers and servers that interop with Zipkin

2rd party Zipkin tracers and servers

Gitter

Google groups

Twitter (the app)

Blogs, Events

1st party tracers and servers

Docs and specs

7 of 9

OpenZipkin Tools and Process

Tools:

  • GitHub for development, PRs, issues and longer discussions
  • Gitter.im for real time communication
  • Google mailing lists (zipkin-user and zipkin-dev) for various questions (but are not as much in use, is my impression?)
  • Circle CI/Travis/Quay/Docker Hub/Maven central/npmjs for building and publishing releases
  • @abesto's build and deployment scripts that streamline the release processes, so that they can be made on a daily basis

Process

Process; or rather the lack of process, which facilitates agility, at least on trivial changes like bug fixes. Somewhat more involved PRs are usually code reviewed, and wait for +1 from a few more developers before they are merged. Major decisions, typically independent from the day-to-day releases, are made in GitHub issues. They are also discussed in the workshops/meetups, that are held every few months or so.

7

8 of 9

Org-related interests expressed at Zipkin

  • We have easy and efficient release processes we want to keep
  • We want autonomy to choose the best tools and repositories.
  • We don’t scare off people with CLAs or burdensome process.

  • We like orgs with “cool projects” which lead to symbiotic effects
  • We want legal protection without switching tools or changing release process
  • We want autonomy to choose our leadership approach (ex BDFL)
  • Some concerns about source or guarantees of funds for events or perks

8

9 of 9

Q&A

9