Almost five years ago (!) I said I was sold in theory on open-sourcing Beeminder. That it wasn’t a priority but was worth doing eventually. To prove that those weren’t empty words, I started beeminding making it happen – beeminder.com/d/bos – albeit at a glacial rate (< 8 minutes/week).
I should hasten to add that open-sourcing Beeminder does not mean becoming a non-profit or ceding any control or anything like that. We’ll remain a normal business with nothing at all changing from users’ point of view (other than, iff we do it right, new features getting shipped faster). I think the idea of a SaaS business open-sourcing their code is surprising to people because it seems like a natural trade secret or something. Like how Coca-Cola supposedly jealously guards their recipe for Coke. And in theory, publishing Beeminder’s source code could allow a competitor with a better marketing budget to deploy a Beeminder clone and eat our lunch.
But realistically, no one with the competence to pull that off would stoop that low. I’d expect someone to be motivated to do that to the extent they thought they could do Beeminder better, in which case our source code wouldn’t help them. We already spell out all our clever ideas on the blog.
Anyway, here’s a long discussion about the pros and cons from 5 years ago:
But the status now is that we’re just ever-so-gradually doing things like separating API keys and such into a separate GitHub repository and other prereqs for making this eventually happen, without actually prioritizing it. I’ve asked this before but if you’d potentially submit a pull request if Beeminder were open source, please remind me of that by checking some boxes in this poll:
I’d hard-commit to submitting a pull request to improve Beeminder
I’d soft-commit to submitting a pull request to improve Beeminder
I might help improve the webcopy or other nontechnical things
I’m excited on principle for Beeminder to be open-source
I don’t think open-sourcing Beeminder is worth it
I think it’s a bad idea even if time/money were no object
It’s probably pretty obvious, but I’m not sure how it’s organized under the hood. If it’s properly modularized, only the non-critical parts are open sourced (collecting data/integrations) and stuff like billing and deploy-related infrastructure are hidden from contributors. There are services like GitLab, who have outsourced their basic service (albeit its also deployable) but they also provide it as a part of their SAAS platform.
I think if done right and with a right kind of license, outsourcing parts of the product may be a good idea as it allows for development to become more rapid (if a person needs a feature he creates PR and voila). If I was interested in creating a similar platform I’d probably start anew anyway (disclaimer: I’m making my own quick feedback platform, to draw graphs on data without the sting, etc), heck one can deploy a PostgreSQL server with Grafana (to draw graphs on the data) if one is dedicated enough. I don’t think the Beeminder code has the same value as the community that emerged around the platform.
I really like the idea of making the UI open first.
(Back up, really I like the idea of picking any one thing and making it open first, but in my app-design struggles, I’ve experienced that when an app is poorly designed as a ball of mud or shanty-town pattern, and there is too much logic in the views for example, one great way to get yourself out of that mess is by drawing a line in the sand and saying “this is where your interface specification goes now.”)
The cleanest place to draw that line seems to be right between the web app that handles user sessions and connections to the backend, and the front-end code that actually runs in the user’s browser.
I’m not saying that Beeminder is badly designed (I haven’t seen the code! so it would be impossible for me to make such a value judgement), but I am definitely saying that if one of the goals of your open-sourcing is that you want to set a good example for other app developers, and you think there are parts that are rightfully going to be on the receiving end of design change suggestions after they are published,
…I’ll be super interested in participating in those conversations!
So, to the idea of opening the code piece by piece rather than all at once. This will make it easier to get actual interested and qualified people to put their eyes on it, and discuss how to make it better!