The developer of the ruby state_machine library (whose name I think might be Aaron Pfeiffer) talks about some of the challenges and reasons for success he and the other developers had in making state_machine a dependable, high-quality, well-adopted library.
I actually know nothing about state_machine (I don’t even really understand what it does), but his description of how to develop quality matches my own experience and observation. If you’re wondering why your open source project is frustrating users, or not attracting users or developers, odds are you have failed to do some of what Pfeiffer specifies.
Of course, doing it right isn’t quick or easy, as Pfieffer notes. You can sometimes get away with developing local software for your own local use cases on the cheap; but developing shared software/libraries/frameworks to meet generalized use cases takes more time if it’s to be succesful. (I think it also takes a degree of skill and experience, something Pfeiffer doesn’t mention perhaps out of modesty).
It’s not a very long article, it’s a bit silly for me to excerpt it, but nonetheless I’ll quote some of the points that struck home to me:
I discovered during this process that it was critical to address every problem or feature that a user reported. If I could not suggest the right way to address the issue, then there was a flaw in the library
While I understand that being the single gatekeeper to this project slowed its progress significantly, I also attribute much of its success to the fact that every single piece of functionality that was added was rigorously scrutinized and made sense with the whole vision in mind.
To that end, I set four critical standards for this project:
- Every feature must be implemented to the highest degree of quality, both from a functional and design perspective
- Every change must be backed by well-written unit tests to ensure functional quality
- A significant amount of documentation must be provided for every feature, whether part of the public or private API
- Support must be provided, at the very least, in the earlier stages of the project
[On supporting integration with third-party libraries…] Every project moves at its own pace and, at least in the post-GitHub world, that pace can be at a breakneck speed. As ORMs make significant changes to their public APIs, updates often need to be made to the associated state_machine integration as a result. Supporting multiple versions of a library can be an minor inconvenience; supporting multiple versions of multiple libraries can be a major problem.
Open-sourcing a small library you whipped up over the weekend or while building a feature at work is easy. Managing that project as it begins to get followers and takes on a grander vision can be difficult. More than anything, I’ve discovered that the hardest part is finding the time to work on it. Granted this is the beauty of open-source, and GitHub in particular, where the masses can help build new features and fix bugs… and all I have to hit is the one-click merge button. However, it’s not always that simple.
As I mentioned earlier, a project like state_machine can require a much more hands-on management style where every change is assessed for consistency, compatibility, quality, and more. After you take into account acting as the support contact, being a core developer, and more, the time adds up.