A Retrospective on my time as Organizer of the SF Cryptocurrency Devs Meetup

In this post I discuss what I learned after seven months of organizing one of the largest cryptocurrency developer meetups in the heart of Silicon Valley — specifically I discuss three lessons, shedding insight on how we overcame the most significant obstacle faced by meetups, oss, and blockchain projects: building a community.

My very first event — Zcash 1/24/18

An AR fashion enthusiast, a charismatic entrepreneur, and a college student walk into a bar. No, that’s not the beginning of a bad joke, its a typical Wednesday night — a night filled with the laughter, chatter, speculation, and excitement following a technical deep dive into yet another exciting application of blockchain technology. Over my seven month campaign as co-organizer of the SF Crypto Devs Meetup group, I had the privilege of leading these events, every other Wednesday, sometimes even three or four weeks in a row. No matter what the topic, How to Contribute to Bitcoin Core, Cross-chain Atomic Swaps, or Discreet Log Contracts, I always ended up awake, late into the hours of Thursday morning, deep down the rabbit hole of trying to understand the why and how?

Alas this all came to an end this past Tuesday night as I handed off the baton to my successor, the wonderful Val Mack, in preparation for my return to Colby College where I will finish my undergrad (two years left, oh my!). So tonight, I sat down and pondered on my experience, the successful events, forgetting to order pizza, Mark Nadal’s neon green pants, and launching Block and Jerry’s. In doing so, one common theme stood out.

Community, the life and death of meetups, oss projects, and the entirety of the blockchain space.

The following are three stories, demonstrating lessons I learned on how to build an engaged, active, and enthusiastic community.

Hack and Chat Sundays

How do you make an open source project appealing? What excites a bored engineer and inspires the effort of opening a PR? Those are some of the questions I pondered as I attempted to create my own open source community.

JZcash

For the first three months of my time with SF Crypto Devs, I led the Hack and Chat Sunday events, one or two Sundays per month. The premise of these events was we provide the coffee, you bring the projects, together we hack. Ultimately, we wanted to foster a community of builders, developing exciting open source software that flourished into the next exciting blockchain project.

The most amazing group of dedicated people showed up, giving up there Sunday to hack around with us. It was great!

Over the course of these weekend events, I attempted to bootstrap a spectrum of (failed) projects:

• JZCash
• A Documentation of the Parity Bitcoin Client
• A JavaScript Telegram Bot
• A Rust Meetup Bot

These first attempts to build something and attract a dedicated community of contributors failed — while they all started with great intentions, people stepped in and made a few contributions and we all learned a thing or two, the excitement didn’t last. Eventually development came to a halt and the community dispersed.

However, we did eventually strike gold.

Me holding the satellite dish in place.

One especially bright and sunny Sunday afternoon, on the roof of the Galvanize workspace, a group of SF Crypto Dev engineers worked together to construct a Blockstream Bitcoin satellite receiver. We had a python professional debugging the gui software, an embedded systems expert explaining how I bought the wrong parts, three of us continuously repositioning the dish, and the rest working through the set (the only set) of instructions we could find.

Six hours later our reservation ran out and we had to pack up. While we were not able to properly align and configure the receiver, the camaraderie and team work was unparalleled; the community present on that day still occasionally reminisce on that experience — if we just had the right parts and if we had tried moving the receiver an extra degree north, we might have succeeded.

Lesson #1: In the world of abundant oss opportunities and developer challenges with rewards, people are most excited by unique and challenging experiences, specifically memorably challenges they can tell their friends and family about.

How cool is it to say you hacked around with a Bitcoin satellite receiver? Certainly much cooler than “I won $100 building yet-another chatbot” or “I made another trivial contribution to X open source project.”

Emergency Readings

One Thursday afternoon, Taariq excitedly posted a link with the following caption:

Check this out! It is the new Hotness! Avalanche, DAGS! 🔥🔥

He was of course talking about Team Rocket’s recently published whitepaper, titled: Snowflake to Avalanche: A Novel Metastable Consensus Protocol Family for Cryptocurrencies

Rob, we need an event ASAP. How about we host a reading session to discuss this. We will call it an Emergency Reading and it will be this Sunday from 5PM to 7PM.

And just like that, Emergency Sunday readings became a bi-weekly Sunday event (my favorite event, socratic style, interactive discussions of the latest and greatest upcoming cryptography schemes, consensus protocols, etc.)

Pretty quickly we had a regular crowd, a dedicated community of people who voluntarily gave up their Sunday, every other weekend, to nerd-out with Taariq and myself. This seemingly came out of nowhere and ultimately made no-sense, at first. Why was a Sunday reading event so exciting? What inspired this dedicated bunch? What incentivized these engineers to spend time during the week, pre-reading, in preparation for the Sunday events?

TLDR: The Pareto principle is real. 80% of what I learned over the course of hosting this Meetup happened at 20% of the events (Sunday Emergency Readings). Of those events, 80% of the contributions came from 20% of the people. Let’s call these people stallions.

Bear with me, I have a point.

At the end of the day, most groups need some sort of leader, someone to push the group forward and to ward against laziness, inactivity, and complacency. Every time we had one of these Emergency Readings, a leader naturally took charge and bestowed upon the group his/her expertise in the subject.

• For Avalanche, a distributed systems engineer explained how everything connected together.
• For Mimble Wimble, I explained the elliptic curve cryptography behind blinded transactions and Pedersen commitments.
• For threshold, proxy re-signatures, Taariq explained his own project’s signature scheme.
• For Grin, Quinten Le Sceller explained the Dandelion protocol.

The experience of the group, and ultimately the success of the event could be credited to the exceptional efforts of a single individual.

Lesson #2: Find your stallion. Every community needs someone to push the group forward.

The Perfect, Patented, Pizza Formula

You simply can’t run a Meetup without pizza.

It was the morning of another event and I was faced with the infamous Meetup dilemma, how much pizza should I order? For those unfamiliar with organizing events, this is a non-trivial problem; order too much pizza and it seems like the event is under-booked, order too little pizza and people can’t focus because of empty stomachs. And there is not a one-size fits all solution; ordering pizza is dependent on a number of factors such as the number of RSVP’s, the size of the pizza, and the choice of the restaurant.

It took me a while to master this challenge. One time I ordered from Patxi’s to discover their pizzas are small and come in six slices — everyone who showed up after the first ten attendees was underwhelmed. The next time I order ten extra-large pizzas from SOMA pizza for an audience of fifty. I end up taking two whole pizzas back to my apartment (cold veggie pizza for breakfast, lunch, and dinner, yum!).

After numerous failures (and reprimanding from Nelly), I eventually figured it out. Here, is the official SF Crypto Devs, patented, precise, formally verified, pizza ordering formula written in rust (proven only under the non-random oracle assumption, aka only works for SOMA pizza).:

fn calc_number_of_pies(rsvps: u32) -> u32 {let number_of_attendees = (rsvps as f32) * 0.33;let number_of_slices = number_of_attendees * 2.0;let number_of_pies = number_of_slices / 8.0;// Don't forget the extra large constant factorreturn (number_of_pies * 0.8).round() as u32;}

Here it is on rust playground if you want to test this tool for your event.

Bottom line, we have had the perfect amount of pizza for our last five events.

A similar story is true for most other aspects of the SF Crypto Dev meetup: Sunday events (as described above), community mailers, the SF Crypto Devs intro slide deck, etc. Everything took time to fine tune. However, once that goldilocks, just right combination was found, it worked (aka find that product market fit — yes, your Meetup is a product that people pay for with their time).

Lesson #3: Keep experimenting. A single, failed event , or an unpopular idea says nothing about the community as a whole. Communities are built over time and may take a while to find their stride.

Conclusion

Chaat Corner was always a favorite!

First and foremost, I want to thank the incredible SF Crypto Devs community! I had a truly wonderful time meeting everyone and can’t wait to come back this winter for an event!

To you, reading this article. Thanks for letting me share this experience with you — if you are considering starting your own community, go for it! I hope one, or all of these lessons help you find success.