Missing the Mailing List

Here’s one little bit (among many) that I miss about working in Solaris Engineering at Sun and Oracle: The Use of Project Mailing Lists. The timeframe for all this is about 2004-2016.

The concept is simple. You dump everyone involved in the project on to a common mailing list (we used Mailman on OpenSolaris) and then you iterate. That’s it. Well, that’s it at least for the conversation part. There’s actually a great deal more involved with the use of mailing lists depending on who’s using the list and for what purpose.

From a communications point of view, most engineers generally already know to trim, quote, thread, bottom post, filter, and use text emails. But if not, many Open Source engineering projects have handy mailing list guidelines to inform new people about expectations for clean, professional online communications. The guidelines help facilitate efficient discussions for everyone involved — people locally, people internationally, existing people, new people.

This is also convenient for community members. So, for instance, if you are remote, when you get up in the morning you simply log in and see all the email from your projects neatly tucked away in a clearly labeled folder — because you know enough to set up filters and folders on your email client. Then you can rapidly parse the conversations that took place overnight because the emails are all properly formatted and threaded as per the community’s mailing list guidelines. Then you can jump in to a conversation at any point and contribute knowing that everyone who needs to see your email will see your email. You can communicate with thousands of people around the world in an organized way, and you can easily switch between a variety of topics on multiple mailing lists. It just works. And it works not only because it’s simple and organized, but also because there is a clear expectation that all project discussions take place on that project list — not in the hallway, not at the bar, and certainly not buried inside individual threads among just a few people.

On OpenSolaris I was subscribed to more than a hundred mailing lists, and those lists generated thousands of emails per month. And yet I never felt overwhelmed with email. Obviously, I didn’t need to see everything every day. I just needed to have it all organized. I needed to know where everything was. This way I could quickly get anywhere I needed to go and contribute if and when I was needed. I also administered more than a dozen lists myself, and I never once felt overwhelmed with admin tasks. I’d clean out the admin queues first thing in the morning and then check them at the end of the day. No big deal.

Additionally, you can use a mailing list to have distributed team discussions — even though there are likely a number of ongoing projects and lists within a team and also cutting across multiple teams. It’s just another list with a specific purpose. How else would distributed team members communicate to each other? Individual email? That doesn’t seem like a good idea because someone is likely to get left out. Hallway conversations? That obviously leaves out people who are remote, and then they are at a significant disadvantage out there on their own. Even worse, when you don’t even attempt to implement an organizing scheme for your team’s online communications, this is what you generally get:

Individual emails with 50+ people on the TO line and a dozen people on the CC line and who knows how many more are buried on the BCC line.
Highly formatted, multi-color HTML mails with massive attachments in different versions that won’t even be attached when people respond.
Multi line email signatures with long titles, high resolution corporate logos, idiotic blinking emojis, and links to piles of external social media accounts.
Threads where people are added and deleted randomly along the way as conversations snake through the company because everyone has to cover their ass.
Responses where people forward mail (instead of just responding) and add a different color text or highlighted text woven neatly into the original mail.
Top posting.
No trimming.
No quoting.
No threading.
No timely responding.
No iterating.
No consideration for anyone outside the local geography.

Most engineers know the list above represents insanity. But what’s really crazy is that people in marketing think it’s all pretty normal. This is something I’ve never come to accept about marketing. But don’t worry, we now have Slack! We’re saved.

And it goes on. It’s a stunning display of dysfunction and we all see it every day. Although some people think this is normal many do not. Many people instinctively know this is a problem because they complain that they get too much email and that everything on the project is confusing. Ya think? Just take a peek inside some inboxes and you’ll see tens of thousands of unread emails like this all lacking any connection to common sense. Heck, I didn’t even know you could have that many emails in an inbox. Also note the lack of folders and filters. But Slack solves that. Right.

After Solaris I spent a pile of time in marketing. At various points I suggested using project mailing lists to help organize discussions and provide a common space around which the team could collaborate. The idea was generally met with silence. However, one time a project manager was kind enough to respond on team call with, “Jim, we don’t do that here.” Well, ok, I guess that settles that.

I sometimes even set up mailing lists, provided instructions on how to use them, and sent mail to the list to force the issue. But people didn’t engage. Instead, they just froze. Or they’d respond back and add people to the CC line who were already on the list. Sometimes they’d CC the original list and sometimes they wouldn’t. That’s when I’d just shake my head, delete the list, and walk away. If there’s no leader on the team who understands distributed global communications and who provides a daily example as a standard then you have no shot. Just accept it. Do what you can on an individual basis to protect your own interests. That was my conclusion from working in marketing following the standard set in Solaris.

So, I feel lucky to have had the Solaris experience years ago. It was a pleasure working with people who just got this concept of communications with very little or no meta discussion about it. By the way, this issue was not specific to Solaris Engineering. I’ve been on Linux user group mailing lists and other FOSS development and policy lists where it was just culturally unacceptable to communicate like I described above. You got spoken to. And fast.

Now, I’ve really only talked about general conversations between team members because we all communicate to manage projects. But things get more interesting as developers engage in technical conversations on mailing lists. They also use the list itself and a number of other tools to get code integrated into source repositories (reviewing code, fixing bugs, testing, etc). See Mailing Lists vs Github for a deeper look. It’s interesting. Otherwise, just search the web on the use of project mailing lists to read some common list policies at some FOSS projects to get an idea of what I’m talking about. The list below may help. And then look at some actual FOSS project archives to see what distributed technical discussions look like for people who need to get real work done (for example, OpenJDK). Contrast all that to how your team communicates — especially if you are in marketing. Sorry for the criticism, but it’s well earned. Actually, I take that back. I’m not sorry at all.

Examples of Mailing List Guidelines

There may be hope coming for non developers, though. Although developers think and work quite differently than non-developers, sometimes the tools themselves can actually influence human behavior and focus people into more efficient paths. See How We’ll All Work Like Developers (Without Learning to Code) from a16z for a bit on that. Also see Jono Bacon’s review of Slack vs Forums for an outline of some of the newer tools for community communications that came along well after mailing lists.

So, I said earlier that I was in Solaris at Sun/Oracle from around 2004-2016. Then Oracle marketing from 2017 to 2021. Now in 2022 I moved back to engineering but this time to Java doing developer relations, or DevRel, as it’s called. DevRel can be implemented in a variety of ways, and it can be hosted in marketing or engineering. Personally, I feel (strongly) that it’s best suited for engineering. It’ll be interesting to compare Java communications to corporate marketing and Solaris engineering. I have a feeling I know what to expect.

Drafts: Original text written in July 2017 after I moved from Solaris engineering to developer marketing. Text updated in March 2022 after I moved from developer marketing to the Java Developer Relations Team in Java engineering. All jobs during this time at Oracle.

Jim Grisanzio

Missing the Mailing List

Like this:

Discover more from Jim Grisanzio