Leaving home

Dear friends at Apiary, it was a great run, but it’s the time to move on. After four wonderful years, my time at Apiary has come to an end. As of December 1st, I’ll be standing back on my own.

I’m starting API consulting company–Good API. Alongside with the API consulting business, I plan to create a whole new product which I hope to unveil at the start of the next year.

Apiary

Apiary was my home. The place where we grew up.

We dared think a plain-text API description can connect worlds of developers and stakeholders. We crowned the term API design and pioneered the design-first approach. We did so in desperate times when everybody around us was generating documentation from the code. We built the first tool to tests API implementations against API specifications. And finally, we created the API style guide to achieve the consistency many across APIs.

We did all this to help everybody build APIs and to give the control to stakeholders. We saw copycats stealing our ideas, tools and even words. But in all this, we were always standing against the odds together.

Today, when Apiary is stronger than ever, we still stand for these values and ideals. Nothing has changed during the time. We still believe the inclusive, contract-first, test-driven, API development is the right way to go.

API Blueprint

Then there is this API Blueprint thing. A couple of semantic assumptions on top of a plain text document is now one of the popular formats to describe APIs. Who would guess? I’m leaving the API Blueprint in good hands. In yours and community’s hands. API Blueprint didn’t need artificial workgroups or Wikipedia pages made by its authors. It only needed you and the community. And you came! I can’t express how proud I’ve felt when the community started to share our beliefs!

And, after we adopted Swagger, we’ve finally got the discussions about which format is better out of the table. After all, is Ruby better than Python? They are entirely different, serving the needs and tastes of different people. Nonetheless, these different people stand united in one goal: To build the best API for their needs.

I’ll leave you with the API Blueprint roadmap. The goals are:

• Reusability
• Style abstraction
• Protocol abstraction

Please stay focused on the API design. My aspiration with API Blueprint was to create the medium for thinking about APIs, not a catalog of bolts and nuts.

If you want to know more about the future of API description formats, please join me for my upcoming talk at APIDays Paris.

I’m thankful for the chance to work with you. You are some of the brightest talents in the API industry!

Thank you!

Yours,

– Z.