Respecting early adopters
Perhaps the trickiest thing when developing an open source library is figuring out the balance between changes you feel are necessary, and respecting early adopters.
Take the case of khroma, the ClojureScript library for providing idiomatic access to the Chrome extensions API. It’s very much a work in progress, and I’m developing it to use on an extension of my own. The way I go about it is exposing functions and event handlers mostly as I need them, to avoid getting sidetracked into surfacing functionality for which I don’t have a practical use case right away.
However, when developing something organically, the question then becomes: where do you draw the line between unifying the way the APIs behave after adding functionality, and not breaking things for those very early users?
It’s a non-trivial question, and it has to be answered in the abstract. Given khroma is a publicly available project, I don’t really have any statistics on how many people are using it. Occasionally we’ll get a question in the form of an issue, or someone will reach out directly, but there’s no unified way to figure out the community’s opinion on what could be breaking changes.
The goal is to end up with a coherent, easy to use library. This means that decisions made early on, while we were still experimenting with the right approach ourselves, might not be the best ones for the library in the long run - or even when going from 0.1 to 0.2.
The intention is of course to always respect early adopters - they are the cornerstone of any platform. I don’t want to unnecessarily trip someone who is using it and will need to refactor working code on upgrade.
With that in mind, I’m aiming to lump together any major library changes in 0.2 (and potentially up to 0.3). These releases will not be focused on library completeness, but instead on defining the approach for exposing functionality. That way, new functions that we add down the road will have a clear blueprint to follow, and we’ll reduce the odds of realizing that we need to break the way an API behaves in order to have a consistent, more idiomatic approach.
If you’re using the current, very early versions of khroma, you should keep up with the changelog. You’ll find a clear separation between breaking changes and additions, and it should give you an idea of the direction that new functions are likely to take.
Meanwhile, I’m opening up some issues for discussion on khroma’s Github page. If you’d like to contribute some thoughts on your preferred approach, stop by and comment!
Published: 2015-10-26
