Links - 29^th May 2022

In games, we talk about the idea of the “magic circle”, a boundary that clearly delineates the space where a game or play takes place as distinct from the normal world. Activities within the magic circle being distinct from normal reality gives people freedom to express themselves more freely and to, well, play (within reason and established safety limits, of course).

A similar thing happens with in-person conferences. The event venue (especially if in a destination location!) serves as a freeing liminal space that helps attendees be present and engaged. Whether you’re at a conference to learn from the talks, to meet new people, or frankly to just enjoy a free employer-paid vacation, the act of being in a different physical place does a lot to get you in a mindset where you’re ready to embrace new experiences.

This is difficult for online events in the time of quarantine! If you’re like me, you’re largely spending 40 hours a week sitting at home, using Slack and Zoom or some other similar text and videoconferencing software. Asking people to spend their weekends at their same computers attending a Zoom conference with a Discord or Slack doesn’t accomplish that goal!

We realized that, even if our custom social space was otherwise a complete and utter failure, the mere act of having it be a new and novel space would still be valuable.

Video chat is far more effective than audio chat at helping convey emotional nuance, and audio chat is equally more effective than text chat. This is important if our goal is to foster new friendships and interesting connections!

But at this point in quarantine, we’re all well aware of Zoom Fatigue. It’s clear that running an entire conference on video or audio chat is a great way to burn everyone out.

As we spoke with potential attendees, we realized there are broadly two types of online communicators: those who are happier communicating online in text, and those who are happier using videochat to the extent that they have the emotional energy. Finding a way to make both groups of people feel comfortable and socially stimulated felt like a valuable goal.

This led us to aim for an event where communication over text chat was the default, but there were many opportunities for attendees to consensually opt-in to escalate into audio or video chat. Being primarily based in text chat lets attendees save up their emotional energy for focused higher-quality moments of video conversation, and grounding those moments in opt-in activities means that each individual attendee can self-moderate how much video chat they can handle.

Our plan for video chat in the space was twofold: we planned to schedule discrete blocks of time for video chat-based networking sessions, but also offer lower-key videoconferencing in every room that people in that room could join at any time.

For the former, we held unconferencing sessions where attendees could propose and upvote discussion topics, which were then assigned to specific rooms. We also intended to schedule breakout room-style networking sessions (where you would be randomly moved into a videochat with 3-5 random people for 10 minutes), but couldn’t find room in our final conference schedule. These are the two structures I’ve seen work particularly well for structured video chat to avoid the anarchy and fatigue of unstructured 30-person Zoom calls.

I liken the work that goes under “glue work” to spackling paste that ensures that all parts of the software delivery for the business is happening smoothly.

However, that is not the same as saying “as a senior leader, everything is your job”. Gaps can happen in many shapes and sizes, and you need to recognize when a gap needs more senior leadership attention instead of trying to absorb them all. In those cases, you should be working on properly communicating the gap and its risk to the business (and risk to which part of the business) and NOT attempting to solve everything. Here are some examples of possible gaps that you should be definitely saying “this is not my job” and instead communicating risk about:

• A team is severely understaffed, and their manager is not advocating for them

• You are involved in planning with a part of the organization and can see clear signs of a toxic work environment

• A critical part of the technical stack is a recurring source of incidents and no one officially “owns” it in engineering.

You might exclaim, “but I can’t stay quiet!”, and I am not suggesting you pretend you saw nothing. But be cognizant of what you can and cannot control as someone who is in leadership without explicit authority over teams. You owe it to the engineering managers of managers you work with to communicate the gap, but you should not put it on yourself to try to resolve the problem without communication.

I have started, lead and maintained many projects over several decades, out of which the most known one is probably the cURL project I founded and have been leading since 1998. I have contributed to and participated in many more projects and I have of course used and kept myself up-to-date with a large number of projects in which I did not personally participate.

I first learned to program on the Commodore 64 as a teenager 1985 and after some years I transitioned over to C programming, first on Amiga and then on Unix systems. I released my first source code to the public in the early 1990s — years before the term Open Source was first coined. I have since then spent many hours every week throughout my entire life contributing to Open Source projects, my own and others'. I have worked exclusively with Open Source professionally since 2014 for Mozilla and since 2019 for wolfSSL.

Because of my background and life with Open Source and probably a lot because of the relative success some of my projects have had, I frequently get questions about subjects related to maintaining Open Source. How to run a project and what makes them succeed? For a long time I have been collecting lessons from my life with Open Source into a list of advice for fellow Open Source library hackers. This document is my attempt to convert those thoughts and experiences into words.

This document is written with you as the intended reader. You are someone who is interested in Open Source and keen to get started or maybe you already are a maintainer and want to get further insights in how other maintainers go about doing Open Source. You might do Open Source in your spare time or work on it full-time as a paid employee.

I am not suggesting that everything I write in there will be a match for you or a good idea for everyone. One of the best features with Open Source is that there is always more than one way to do things and that everyone is always free to go their own way should they decide to. I give you my take and my advice. You are free to decide what to do with it.

I have been wanting to read Data and Reality for a long time but I’ve only been able to find the 3^rd edition in print, which I’ve heard was ruined by the editor cutting out large sections and inserting his own heavy commentary throughout. Jonathan Edwards pointed me at this pdf of the 2nd edition.

It’s slow reading, but I think it’s helpful. I’ve been thinking a lot about the fine details of how to model data in imp, and this book is a cornucopia of counter-examples and tricky edge cases.

It’s also lending weight to my belief that it’s a tactical mistake to think of data-modeling as being about modeling the world, which quickly leads to being buried neck-deep in philosophical questions. Better to focus on modeling the desired behavior of the computer system, which is at least tractable.

So rather than asking eg “when are two things actually the same thing”, you can ask “when will our system need to treat these two things differently”.