Uncategorized

Happy 1000th, Bridgy

Bridgy, my little IndieWeb side project, hit a milestone a couple days ago: 1000 users! Congratulations Brett Glisson, you win the prize!

1000 isn’t a big number. We’re a long way from viral marketing, growth hacking, and customer acquisition tracking, and that’s fine with me. I built Bridgy to scratch my own itch, in fine open source and IndieWeb tradition, and only launched it publicly because I thought other people might have the same itch.

Milestones are good excuses to count blessings, and Bridgy has plenty to be grateful for. Kyle Mahan has stepped up in a major way, building substantial new functionality and supporting servers and users alike with aplomb. He’s basically a co-owner at this point. You rock, Kyle! Emma Kuo, Barnaby Walters, and Kartik Prabhu have also contributed great code, and the IndieWeb community‘s support has been invaluable. Thanks everyone!

Milestones are also good excuses for navel gazing, so here are some graphs. They have pretty colors!

First, user growth. Clearly not exponential, but it is keeping up a steady clip. Also see the cumulative graph at the top.


Many people sign up for more than one silo – Facebook, Twitter, etc. – so it’s technically 1000 accounts, not users. I’d guess there are only 400-500 distinct users. It’s not always easy to tell the difference automatically, though, and 1000 is a nice round number, so I’m going with it.

Now, the stuff Bridgy actually does. Note that the second graph is log scale, since I threw in everything but the kitchen sink. Tufte would have a fit.


So much for the candy; now it’s time to eat my vegetables. What lessons have I learned so far? What has building Bridgy taught me?

Honestly, I’m not sure. I can’t think of anything particularly interesting or insightful. We need a balanced meal, though, so here are some thoughts.

First, the “scratch your own itch” thing really worked, at least in this case. I always knew what to build next, and how to prioritize, based on what I wanted for myself. Tellingly, the major features I added later – Bridgy Publish and webmentions for blogs – weren’t as strong itches for me personally, and correspondingly, each one has seen less uptake than the last. The graph ain’t lying.

Second, I want happy users, but tech support is no fun. When someone has a problem or a question, I try to find and fix (or automate away) the root cause, or at the very least update docs so the next person won’t need to ask. It’s not perfect, but I think it helps…

…or maybe it’s just that for most users, Bridgy is fire and forget. They sign up, poke at their user page, maybe skim the docs, and then never come back. They don’t need to. Comments and retweets and +1s start showing up on their web site automatically. This is my favorite kind of UI: none at all. And thank God for that, since I’m worthless at UI design.

Lastly, unit tests. I won’t go all rabid religious dogma on you, but man. The freedom to make big changes, refactor core logic, and then push that new code live, confident that it won’t break anything? It’s incredibly liberating. Not to mention that running them before deploying has saved my ass on more than one occasion.

Automated monitoring paged you at 3AM because the new release has a regression bug? Good. At least you caught it. Slept until morning because your tests caught the regression before it went live? Priceless.

Anyway. Contributors are still cranking away, and I’ve been pushing out a steady trickle of tweaks and bug fixes, but that’s slowed down recently. None of the remaining feature requests are above my itch threshold, so they may not happen anytime soon. I happily accept pull requests, but otherwise, Bridgy is basically on ops autopilot right now.

Keep it up, Bridgy! Here’s to 1000 more!

Standard

31 thoughts on “Happy 1000th, Bridgy

  1. It didn’t quite fit as part of the post, so here’s a footnote.

    If the unexpected happens and the trickle of signups suddenly becomes a flood, I’m pretty confident Bridgy will scale. App Engine does most of the heavy lifting, and webmention sending and silo polling are intentionally serialized, across the entire system, so that they’ll degrade gracefully. If a million people signed up overnight, it would cap out at polling one silo account and sending one webmention at a time. Poll frequency would slow down a bit, and webmentions might be delayed, but workload would remain more or less constant.

    Ironically, the one part that probably won’t scale is – of all things – the users page. :P

  2. Also: my data and methodology for generating the graphs in the post. Bridgy has regular automated backups, so I downloaded the last full backup, wrote a script to parse and munge it, imported the output data into a Google Docs spreadsheet, and used that to generate the graphs.

    Before settling on Google Docs, I tried Wolfram Alpha, Excel, and Google Charts. Wolfram Alpha did some cool analysis and visualizations automatically, but its data import feature was really flaky, and the learning curve to make the graphs I wanted looked too steep. Excel was better, but I couldn’t quite get the exact graphs I wanted, probably because I don’t know how to use Excel. :P Google Charts would have worked, but I would have had to do all of the data processing myself. What am I, a farmer?

  3. Hi, and congrats for brid.gy! It used to work for me, but when I wanted to tweet my last blogpost, I repeatedly get this message.

    Error: {“errors”:[{“code”:32,”message”:”Could not authenticate you.”}]} HTTP Error 401: Unauthorize

    What can I do? Thanks!

  4. Good luck solving it. I’ll have an eye on that github string. Thanks!

    I’m a total coding dummy, so I can’t help you. But with the indie web wp plugin and bridgy even I can use webmentions. Thanks again!

Reposts

Leave a Reply

Your email address will not be published.