Open source?

Akrasia
1

Hi all. This is my first post on the list, although I’ve been lurking for a while.

I just recently started a goal for myself, and as a non-native English speaker, I found some of the interface confusing and I didn’t want to push any buttons randomly without knowing what the consequences would be.

For example, the term “ex out” (in the tooltips of the “dial road” fields) made me unsure about what that button did, until I realised it meant “clear”. Same for “dial-it-in” (I deducted it means “apply changes”) and indeed “dial road”, which could be more clearly titled as “road settings” or something to that effect. Btw, I still have no idea what the “retroratchet” button does.

Also, I noticed that the area around the “retroratchet” button doesn’t quite line up with the “dial road” area (in my Firefox/Ubuntu setup). It’s a small detail, but precisely because of that, it should be a quick fix.

For these reasons, I started wondering: have you guys ever considered making the source code for Beeminder (only the web interface) open-source? That way people could not only point out possible problems but even contribute fixes and enhancements. You’d still control whether to accept contributions, so as I see it, it’s win-win. Besides, this would probably accelerate getting Beeminder into the “silver platter” state that 30% of people can use.

Thoughts?

1 Like
2

Btw, I had already come across https://github.com/beeminder but completely forgot to mention it in my post. I’m mentioning it because it’s relevant, but what I said still stands.
Also, I just found the “we use that” post, which is also relevant: http://blog.beeminder.com/weusethat/

1 Like
3

Sorry for the noise. I just realized I also missed the uservoice [1], the “user-visible improvements” goal [2] and its twitter log [3], and the trello board [4]. I’m adding them to this thread for convenience, but perhaps some of these links could be centralized somewhere in the website.
Currently only uservoice is linked in the footer, but maybe there could be an extra footer section “Get involved”, “Development”, or something to that effect, linking to this mailing list, the trello board, the uservoice, the UVI goal & twitter log, and so on.

[1] http://beeminder.uservoice.com/forums/3011-general
[2] https://www.beeminder.com/meta/uvi
[3] https://twitter.com/beemuvi
[4] https://trello.com/board/website/4f079dbc30a67d1864012d6b

1 Like
4

Waldir, thanks so much for collecting these links and starting this conversation on open source. I love the idea of adding a link in the footer – maybe “Community”? I’ll paste the full list of everything we know of below in the meantime. [1]

As for open source, I think I’m sold in theory and just need to get around to actually doing it. Here’s the list of pros and cons we came up with last time this came up:

PRO:

  1. contributions from superfans
  2. feels like a good thing to do (social efficiency!)
  3. would dissuade folks from making an open-source version of beeminder themselves

CON:

  1. hassle of purging things like stripe keys from git history; worse: unknown unknowns buried in there. (stripe keys can actually just be revoked/regenerated)
  2. could lower acquisition price if we ever wanted to sell (i could certainly see doing beeminder forever but i hate to limit my future self’s options (unless I think he’ll be an impetuous ass, of course, and it’s for his own good))
  3. competitor with big marketing budget could eat our lunch? (really doesn’t seem likely to me that the availability of our code would affect this much)
  4. embarrassingly ugly hacks!

As a compromise in the meantime we should open-source as much as possible at http://github.com/beeminder

[1] Links we know of:

  1. Blog: http://blog.beeminder.com
  2. Uservoice: http://uservoice.beeminder.com
  3. Trello: http://trello.com/beeminder
  4. GitHub: http://github.com/beeminder
  5. Twitter: http://twitter.com/bmndr
  6. Subreddit: http://reddit.com/r/beeminder
  7. Google Group: http://blog.beeminder.com/akratics
  8. Google+ profile: https://plus.google.com/118275811754025086770/posts
  9. Google+ community: https://plus.google.com/communities/118226695073742284301
  10. Changelog: http://twitter.com/beemuvi
  11. Facebook: http://facebook.com/Beeminder
  12. Linkedin: http://www.linkedin.com/company/beeminder
  13. AngelList: http://angel.co/beeminder
  14. App.net: http://app.net/beeminder (mirrors Twitter)
  15. Pinterest: http://pinterest.com/beeminder (empty)
5

CON:

  1. embarrassingly ugly hacks!

FWIW, number 4. is just a rationalization

1 Like
6

I’m a big open source guy, and in fact work for my current employers in the role of helping them to figure out what they should open source, and how they should do it. But the Beeminder UI doesn’t strike me as one of the more obvious things to open source here. In fact, I’d probably start with the graphing libraries you guys have obviously built for yourself!

I agree that the UI is confusing. There are still bits of it that I don’t grok. I think the main problem is that a Beeminder has a lot of jargon. Which isn’t necessarily a bad thing. But the UI doesn’t bootstrap your understanding of it. It took me several months before I figured out what “weasel proof me” actually mean.

A more obviously solution to this is UX improvements and documentation. All sorts of approaches you could take. I think I would probably favour in-situ documentation. i.e. The availability of help bubbles, or similar. Or even guided tutorials. Perhaps even a “what is this?” button that you could click and then use to find out more about a specific part of the page.

Agreed also that the links to the various places to send feedback, etc, would be beneficial. Perhaps just a single page that lays them all out, and then a very prominent “Feedback” button somewhere.

1 Like
7

Re. Beeminder jargon: Perhaps an opening here (if a tangent) for me to mention the Beeminder glossary that isn’t. I put in a request for one here a while back, with the thought that confusing terms in the UI could link to their definition in the glossary:

See the discussion below that post for Daniel’s links to the as-yet-unpublished, and incomplete, glossary. I filled in a few definitions and added a few entries in a burst of enthusiasm at the time, but it clearly hasn’t made it to the front burner. I still think this would be a great idea.

(As for a place to send feedback, Noah, on the Beeminder site you should be seeing a big red “feedback” tab on the left edge of the screen, are you not?)

Matthias

1 Like
8

Great to see there’s interest in this. Allow me to reply to some comments:

First, regarding the cons that Daniel mentions:

  1. could lower acquisition price if we ever wanted to sell (i could
    certainly see doing beeminder forever but i hate to limit my future
    self’s options (unless I think he’ll be an impetuous ass, of course,
    and it’s for his own good))

I believe the code isn’t necessarily the main value Beeminder provides. Of course, the core me-binding feature is the key to make this all work, but technically anyone skilled enough could do that. What makes Beeminder so uniquely valuable is the community, openness, and the way you guys participate and interact with us users in conversations like this, integrate feedback quickly, beemind your own user-visible improvements work, etc. Starting a community is much harder than most people think, and a perfect platform will easily lose to a less usable one if the community nurturing spirit is lacking (case in point!)

  1. competitor with big marketing budget could eat our lunch? (really
    doesn’t seem likely to me that the availability of our code would
    affect this much)

Same answer as above. I actually have been thinking about this recently, and read about the concept of “open company”, a term which at the moment has mostly ad-hoc definitions [1][2][3], but that comprises common ideas such as radical transparency, open-sourcing as much as the code as possible, and selling the service, support and advanced options, rather than the product itself.

  1. embarrassingly ugly hacks!

Either they’re embarrassingly obvious, in which case they’ll be quickly pointed out and fixed, or they’re ugly but hard to do right, in which case they’re not that embarrassing. In any case, I found embracing my own weak self-binding abilities and adopting Beeminder actually lifted a weight from my chest and made me self-loathe myself less. Perhaps opening up your hacky code to public scrutiny will also make you accept its nature, and make it have less of an embarrassing effect as it does now (paradoxically enough!)

  1. The First Open Company - Old Gittip Blog
  2. http://www.fastcolabs.com/3008944/open-company/why-i-made-my-payments-startup-an-open-company
  3. Core Values | Atlassian

Regarding Noah’s comments:

I’m a big open source guy, and in fact work for my current employers in the role of helping them to figure out what they should open source, and how they should do it. But the Beeminder UI doesn’t strike me as one of the more obvious things to open source here. In fact, I’d probably start with the graphing libraries you guys have obviously built for yourself!

Well, we could certainly have simply more tooltips on the interface and focus on open-sourcing the graph-generation first, since it’s rather slow at the moment. But I don’t think the slowness is that much of a detriment to Beeminder’s use. I think a usable and intuitive interface that’s slow is better than a snappy interface that is somewhat confusing.

I agree that the UI is confusing. There are still bits of it that I don’t grok. I think the main problem is that a Beeminder has a lot of jargon. Which isn’t necessarily a bad thing. But the UI doesn’t bootstrap your understanding of it. It took me several months before I figured out what “weasel proof me” actually mean.

Exactly. I couldn’t have said it better.

Finally, about that Matthias said:

Re. Beeminder jargon: Perhaps an opening here (if a tangent) for me to mention the Beeminder glossary that isn’t.

That’s a great idea, but it would be nicer if one wouldn’t need to consult a separate document to understand Beeminder’s interface. Even if we have to resort to extensive “tool-tipping”, the ideal approach, imo, would be to have the interface be self-explanatory.

9

First, I agree with all your points about open-source.

Finally, about that Matthias said:

Re. Beeminder jargon: Perhaps an opening here (if a tangent) for me to
mention the Beeminder glossary that isn’t.

That’s a great idea, but it would be nicer if one wouldn’t need to consult
a separate document to understand Beeminder’s interface. Even if we have to
resort to extensive “tool-tipping”, the ideal approach, imo, would be to
have the interface be self-explanatory.

The thing is, “self-explanatory” is impossible. Something can only be “self-explanatory” to the extent that it meshes with users’ expectations, past experiences, etc., which are wildly different from user to user. You could try to use language that seems intuitive to you, but it will turn out to be jargony to someone else. (In fact, as an example of the converse, I personally found beeminder’s interface to be quite intuitive and easy to learn—apparently it just so happens that my ideas of what are intuitive match well with those of the beeminder term.) Since beeminder has a lot of unique concepts I think it’s actually better to just make up new terms for them and provide users with lots of help learning what they mean—although I agree that aspect could be improved. One longer-term idea which would probably help a lot is to have an interactive tutorial/guided tour thing—when someone first signs up, it takes them on a little interactive tour of the interface, pointing out and explaining various things. More tooltips, a glossary, and lots of “what’s this?” links (which e.g. pop out a paragraph from the glossary) would be great too.

1 Like
10

I would be a big proponent of open-sourcing some stuff if it would mean that the graphs would be done interactively in javascript. I think that would be a big improvement.

1 Like
11

Since beeminder has a lot of unique concepts I think it’s actually better to just make up new terms for them and provide users with lots of help learning what they mean—although I agree that aspect could be improved. One longer-term idea which would probably help a lot is to have an interactive tutorial/guided tour thing — when someone first signs up, it takes them on a little interactive tour of the interface, pointing out and explaining various things. More tooltips, a glossary, and lots of “what’s this?” links (which e.g. pop out a paragraph from the glossary) would be great too.

Exactly. Let me be clear about this: I do think Beeminder is fantastically well designed, and does a great job in general of being intelligible. But there are a few particularly opaque bits, and they’ve also introduced a lot of terms that, while useful and creative and amusing, are just not obvious. I wouldn’t even call them jargon, exactly, since they’re specific to Beeminder. I defy any of you to locate a clear explanation of “retroratchet.”

Waldir, a completely transparent UI is a terrific goal, but that’s really difficult to achieve when you’re doing things that people aren’t already familiar with.

1 Like
12

Thanks, Matthias, for nudging us again on the glossary. I think it’s a good candidate for our next blog post. Jill [1] just overhauled it for us so there’s something filled in for every entry now, though it still needs work. http://doc.bmndr.com/jargon

That big red “feedback” button is surprisingly easy to miss. I think it’s like banner blindness [http://en.wikipedia.org/wiki/Banner_blindness].
And the bigger problem is that it’s only for uservoice. This list, akratics anonymous, is still the most active user community.

[1] beeminder.com/aboutus

13

@Brent, @Matthias: to clarify, when I wrote self-explanatory interface, I meant it literally: I have no pretension that a universally intuitive interface is possible; instead, i.e. in-place help such as tool-tips is invaluable to help the interface explain itself to those who don’t get it right away.

Regarding the glossary, I think that’s great that a collection is being made, but I’d hate to have to navigate to a separate page and search it if I don’t understand a particular interface element. I’d much rather just hover it and read the tooltip. It’s like when I’m reading a book that uses endnotes instead of footnotes (related & amusing: [1]), forcing me to go back and forth all the time. But both goals are complementary: tooltip contents and the glossary should be kept in sync.

[1] http://targuman.org/blog/wp-content/uploads/2012/01/Fox_OnFootnoes_HS.pdf

Guided tours may be a nice touch, but shouldn’t be the main way to allow users to get familiarized with the interface. I for one never liked them, especially because I don’t know whether what’s coming next is relevant to me, or how many steps (and how long each will take) are still to come until it’s done.

And the bigger problem is that it’s only for uservoice. This list,
akratics anonymous, is still the most active user community.

Yeah, I wonder if having such a large variety of communities isn’t detrimental to the health of each. But that’s a subject for another post :slight_smile:

14

Regarding ‘open source’:

The question is really about how best to turn the enthusiastic coding capacity of Beeminder’s power users into improvements of Beeminder as a platform.

I think a very interesting move for Beeminder to make, would be to figure out some way of abstracting the integration of various data sources so that most anyone can add (or at least submit) new ones. There are going to be more and more ‘quantified self’ data sources, and most of them are going to allow access to the gathered data via an API. There’s an opportunity for a unified ‘personal analytics platform’ to arise – like, how are the number of miles I walk per week, and my weight, linked? How is the number of drinks I have on Tuesday night linked to my work performance on Wednesday? Basically how do we combine these various sources of data to present an integrated view of a person’s life and how to improve?

I can imagine a system where there’s a Beeminder ‘integration builder’ interface. Users write snippets of Javascript, which you can run periodically (basically the same way the existing integrations work), using a server-side Javascript runtime (like therubyracer – have the feeling there’s a more popular gem for that now) … they would use the 3rd party API to fetch the data, then Beeminder’s own API to post the data into the Beeminder account. You’d have to have some way of monitoring what these bits of javascript are doing (seems ripe for abuse), but there could be a way there that end-users could write and test out their own code to integrate with Beeminder, in this way you could integrate with more services, more quickly, and have a neat way to encapsulate this stuff and keep it out of your main codebase.

The graphs are awesome (some people are just not quantitative and do not understand graphs), the graphing and the carrot/stick of Beeminder, this should be your ‘special sauce’ and not open-sourced. I would invest in this especially, ways of making the graphs faster and nicer (made with js canvas instead of server-side generated images, faster and less resource intensive), perhaps ways of annotating the graphs, perhaps ‘personal analytics’ (what I was mentioning above).

At some point I could see people being handed out a device by their doctors or employers along with a ‘package of analytics’ relating to their weight, how far they are walking, and so on, and they could be led in this way into improving their health. We are the early adopters investigating the tools of ‘quantified self’ for self-improvement, soon there will an ‘assembly line’ simplification/popularization to roll out these tools to people en masse.

Kevin Trowbridge
Software Developer
Lower Haight, SF
http://kevinmtrowbridge.com

1 Like
15

I’m a fan of opensourcing it - esp to increase your integration possibilities! :slight_smile:
I’m increasingly using beeminder as a general life logging app.

-Jolly

1 Like
16

Nothing to add but to say I agree with you 100%.

17

I was also considering that the graphing algorithms should be the secret sauce. The idea of making it really easy to do integration is an excellent one. I also love the idea of correlating different statistics, Though I’m not certain that that part is very good for open sourcing, Just because it’s tricky to get statistics right.

1 Like
18

I, too, wish for JS-rendered graphs.

Open-sourcing things can be a good idea, but it’s important not to see open-sourcing as magical pixie dust that will quickly increase the commit flow. Making a project open source has a lot of costs, which will only be recouped over the long haul:

  • Reviewing all of the code that you want to open source for secrets that could compromise security.
  • Improving parts of the code that are embarrassing or too coupled to infrastructure that isn’t going to be made open source.
  • Documenting how to get a development environment working.
  • At least lightly documenting the architecture so people have an idea of where to go if they want to contribute.
  • Establishing a contribution policy (and probably a CLA).
  • Additional communication overhead for communicating with the open source community so that contributors don’t do work that you’re already working on.
  • Time spent triaging and working with features that may not have been high internal priorities (or risk pissing off the open source ecosystem).
  • A general willingness to cede control over the precise direction and priorities to a larger group of open source people.

Of course, there are many benefits, especially over the long haul:

  • Gaining additional contributions from open sourcers that would have been expensive or technically impossible to do in-house
  • A vibrant community of people that are interested in the product, its direction, and are knowledgeable in the implementation
  • People willing to do cleanup work in order to become familiar with the project and become contributors
  • Getting insight into product direction by people willing to put their money where their mouth is and dedicate time to implementation (this is the flip side of some of the negative above)
  • A recruitment pool that is already familiar with the product and its implementation

I guess what I’m saying is: open-sourcing anything is a huge commitment that has significant benefits but also significant costs. The community will expect you to treat them well, pay attention to them, and accept their feedback and pull requests. This costs time and energy. If things go well, this time and energy is recouped (and then some) over time. But the Mythical Man Month principle applies.

I have some experience with open source projects and would be happy to answer any questions people might have.

2 Likes
19

Yehuda, this has been hugely helpful and we’ve been talking about it a lot amongst ourselves. You’ve made me more excited about open-sourcing in the long term and more wary in the short-term, which I guess is exactly your point. :slight_smile:

Come to think of it, that makes it the perfect thing to beemind, lest it be something that we perpetually want to get to “some day”. Cf blog.beeminder.com/tuit

So, here I go: beeminder.com/d/boss
It’s measured by TagTime, and the rate is ridiculously low but I’m kind of following Nick Winter’s advice – blog.beeminder.com/nick – plus the point is just committing to not let this languish on the backburner forever. Precommit-to-recommit is on so it’s now pretty much guaranteed that this is eventually going to happen, unless I explicitly decide it’s a bad idea, which seems unlikely.

Thanks again!

PS: Are these rumors true about you moving to Portland? If so you should check out our pomodoro poker hack nights. (Same goes for anyone else on this list who finds themselves in Portland on a Wednesday night. Email me for the details!)

20

I meant to add that Kevin Trowbridge’s idea of an “integration builder” is really good and seems like a good place to start. I don’t know that the graphing needs to be secret sauce but we can delay that decision. I’d love to do more with personal analytics too!

Thanks again for this awesome discussion, everyone!