Skip to content

All we love and cherish is of the nature to change and grow apart from us


There is no escaping this separation

the five remembrances of the Dharma

Dear ones,

Hello, and welcome to the end of my silence out here as I navigate how every aspect of my life has changed, including and especially my own wild heart.

Now that I no longer work for Red Hat but rather run my own consultancy, Open Community Architects (OCA), I’ve decided to have OCA publish a good portion of the content I want to write that once fit best here. This is for two clear reasons, in this order:

  1. OCA represents my current vision and understanding for how to do this Open Collaboration thing, so it is the natural and better platform for those ideas, opinions, and contributions/artifacts. And as OCA grows with other humans, their voices will help evolve the OCA voice just as I’m sure my own mind will evolve. (Constant mind evolution is one of my motivations of engaging in Open Collaboration.)
  2. It is the best content to write for search engine results around the business.

So that’s a whole portion of the content that was traditionally on this blog — Open Community-related content but just MHO (my humble opinion.) With that merged into a new upstream repo-for-my-thoughts, what remains is largely the portion of this blog about me and aspects of my personal life over the years, like family and urban farming.

My personal life has undergone a lot of changes in the last few years, and I know I’m not alone in that — I see you and how hard it’s been for you, too.

For me, big changes include getting divorced in 2022 after 24 years of marriage, and no longer being with Red Hat after 21.5 years Spring 2023. I’m working slowly but surely each day toward feeling and being relatively autonomous and self-regulating.

There is a lot I want to write, long-form posts and essays, articles, poems, short fiction, etc. But that really has nothing to do with my “i, quaid” brand. That is instead “Karsten Wade”, and my intention is whatever I choose to write about my personal life, experiences, sorrows, wishes, and all creative output under my own given name is now going on

That leaves the “i, quaid” blog for … I’m not entirely sure what, but I do think I’ll have things to say in this public sphere where it’s not about any of the above specific things. It is going to continue on this website, however much it is and whenever it wants to come to life.

i, quaid am of the nature to die, there is no escaping death

– personalization of the third remembrance

Call for help: I need you, the Open Source Way needs you

Sometimes we just need some help, like how these pliers helped me pull the protective cover off this Sriracha when my hands were hurting too much to do it. (Image licensed CC BY SA 4.0, Copyright 2022 Karsten Wade

Thank you for reading this, I appreciate your attention and will only take a few minutes of it. In short, issues in my personal life are making it hard for me to pay attention to the Open Source Way project in the ways it needs, such as creating a community governance, shepherding the guidebook’s 2.1 release, and doing more publicity as a community. Now is a time when we really need your help, both to shape and to motivate the project. Will you add your voice to this email-forum thread?

Read on for more of the background, if you wish.

Since the Open Source Way 2.0 guidebook was released in Dec 2020 and announced in April 2021, my actions for the Open Source Way project have been based on our own suggested practices: I went looking for users.

While I was giving talks (at Upstream 2021, at DevConf US 2021, at Open Source Summit Seattle 2021) and attending events where I talked with a LOT of people (KubeCon NA 2021 and All Things Open 2021) , several of you have been writing chapters and thinking of printed versions for a 2.1 release. In fact, a few people I met at conferences in the Autumn of 2021 were interested in writing content for the 2.1 release.

There was a clear rise in interest, and it became common to meet people who were familiar with the guidebook, had read it, or even distributed it to other people. And even as I was turning my attention toward a fascinating new project, I was hopeful about keeping the slower velocity toward the 2.1 release.

But while all of this was happening, issues with and illnesses of people in my personal life were brewing and stewing. Some of these I’ve been open about, such as the passing of my Father in Dec 2021 after 18 months of lung cancer treatment made ultimately unsuccessful by the effects of COVID-19 on the medical system and his inability to get timely and safe treatments. Other issues long predate the 2020s, with some elements coming out in my Twitter feed of #DharmaBuddies meditations, but ultimately some of the issues with the biggest impacts on me are still an ongoing story and not ready to be told.

I’m also coming up on my first year of working with medication to treat ADD and cPTSD. One of the things it does is give me the capacity to take care of myself, especially when it’s hardest to do so. I’ve found that I do best on days when I can follow a routine that includes two to three hours of specific elements at the very start of my day, including yoga, meditation, and exercise in an unhurried way. That gives me the best daily chance for “being able to”—meaning without those daily elements, I am more disabled and more likely to fall into unhealthy patterns.

So in all that, a main reason I’ve been so absent this year is I’m actually taking care of myself. And I’ve tried to keep some key people appraised about what is happening with me. Which now includes all of you, my community of open source practitioners who care. I have had so much support these last few years, there are people there for me wherever I turn. And I’ve been able to be there for other people in more and more meaningful ways. I so appreciative all of you, thank you.

If you’ve made it this far, I will invite you once more to bring your voice and participation to this thread. Regardless, I look forward to seeing each of you and hopefully working together again in the future.

Microphone check, one two, one two


Well, hello there.

It’s clearly been a long time since I’ve blogged here. If you want to know why, I’ll tell you, extensively, about the intervening time … but over on my new personal long-form writing site at It’s not ready yet, I’ll let you know when it is via an blog post and on my @quaid Twitter feed .

The ‘i, quaid” blog is waking up as part of my returning to active duty as a community manager. I currently have two projects in my portfolio, Operate First and the Open Source Way. Watch this space for more about both those projects.

In the time since I wrote last here, I’ve been leading the effort to write the 2.0 version of the Open Source Way, a guidebook for community management best practices. There’s a whole story there to be written, but in short: from the Spring of 2019, through content completion in Dec 2020, to release announcement on 13 April 2021, we wrote a guidebook. We wrote this guidebook as a community of collaborators using our own best practices. You should check it out. There’ll be more from me about this subject on this blog, as I shift to the “attract users/readers of the guidebook” phase of community management.

Also during the last few years I was doing (and finishing) a number of things in the CentOS Project as a Director on the Governing Board, a seat I held from it’s formation in 2013/2014 until my recent departure in April 2021. I’m still writing my retrospective for the CentOS Project blog, I’ll alert in the same channels when that is done. In short, we set out to achieve some goals in 2013 that could change the world. I think we see the culmination of that with CentOS Stream. I detailed all that in another blog post, Balancing the needs around the CentOS platform. Now it’s time for me to get out of the way and make room for the next evolution of leadership for the project. I’m not abandoning the CentOS Project, just now I’m in charge of myself and my own experience. If I have more to say on that subject, I’ll send out the alerts when it’s published.

In and around all this I was Managing Editor for one of Red Hat’s blog properties in the Office of the CTO at Plus all the many other little things that fill the time in Red Hat’s Open Source Program Office (OSPO).

And that’s the quick catch up on the professional open source advocate side. It’s good to see you.

## 30 ##

Dangers of in-person meetings for an existing community


It is inarguable there is a lot of value that we humans get from meeting with people in person. For a free/open source software project, this is often cited as the glue that holds together people whose normal interactions are textual (email, IRC) and lower-resolution than an in-person interaction gives. People who are bound together not by an employment agreement but rather a social agreement.

(I am writing this from the perspective of a person whose ability to travel has wet and dry seasons. Some years I only make one or zero events. Other years I’m on the road for events for six or more months. On more than one occasion I have had to cancel attending, and due to my personal situations I always have to plan as if I may cancel. Often I simply don’t commit until the last few weeks, so I end up making only 50% of what I might attend. Whenever I cannot be at an event, I experience the negative side effects of feeling left out, of knowing I’ll never catch up on the actual conversations that occurred, and being aware of the conversations that never happened because I wasn’t there. I’ve also telecommuted for 15+ years, which has provided many opportunities for me to be affected at being distant from others at in-person work meetings.)

Before I get to the problems (and solutions to the problems), let’s check up on some of the benefits of in-person events:

  • Builds stronger relationships and trust.
  • Increases communication quality.
  • Deepens understanding for people who are even moderately capable at reading body language.
  • Improves friendships through non-work, social interaction and shared experiences, even bonding through negative experiences.
  • Increases empathy and patience.
  • Promotes shared innovation due to a much greater ability to throw around ideas and understand each other’s problems.

However! There are risks to so much emphasis on in-person meetings for an existing free/open source software community.

It is possible to never, ever meet in person and still have a very productive relationship and community. In fact, the odds are that the majority of the members of an online contributor and user community will never be able to meet in person.

One risk is that knowing there will be in-person meetings becomes a disincentive to making remote meetings and other interactions work better. It’s important to put equal amounts of energy into the remote meetings (read below for more ideas on this.)

In person meetings create a two-tiered structure in a community — those who can attend & those who cannot. There is a negative effect to feeling “left out” from all the fun, as the social media and blog posts roll in, and in-jokes for all the people who attended flow across IRC. This drives a further wedge between the tiers of the community that only gets wider as it becomes clear some people are always in the ‘can attend’ and others are in the ‘never can attend’ groups. The ‘can attend’ group gets drawn closer into the decision and leadership circle, which means they tend to make decisions toward in-person meetings — “We’ll talk about this at the conference.” They have less incentive to create and participate in higher quality remote meetings because an in-person meeting is always just around the corner. Another effect of this “wait for the event” is a subset of the whole community is more able or perceived as being the doers. People who cannot attend may withdraw more from the decision and doing process because they don’t feel they can live up to the requirements.

In-person automatically reduces the social and work effectiveness of people who cannot attend because they are not in the clique. It is also a challenge for anyone who is shy or introverted or generally has challenges with social interactions. It is a challenge for people whose capabilities do not include the easy reading of social cues.

In terms of barriers to entry, having to attend in-person is just about the highest barrier we can erect. Due to various life circumstances, a majority of a community will likely never be able to travel to events, even just a single annual one.

And those are just the problems that occurred to me; I’m sure there are others.

But there are solutions! From following the rule that decisions don’t exist unless they are on the mailing list to focusing on the quality of remote interactions:

  • A community can make the remote interactions higher quality – make regular, always-remote meetings rewarding and fun.
    • Have open video meetings where everyone has a cup of tea or coffee, or nice wine or cold beer.
    • If you have a budget, you can order pizza to be delivered to each meeting attendee simultaneously around the globe.
    • Everyone can have the same coffee/tea mug to bring to video meetings.
    • Practice at this improves skills, thinking, and tooling around the remote experience.
  • Enforce the rules about not watercooling decision processes.
    • “If it’s not on the mailing list, it doesn’t exist.”
    • Make having regular online interactions as a community a key part of your processes as well as fun.
  • Do social, fun things together from remote.
    • Play an online game or some other group online activity.
    • Watch a show or movie online, either together or on a schedule, like a book club. Create some common experiences that are not about working on the project directly.
  • Find ways to delight and reward people who cannot attend, etc.
    • Make a t-shirt or other item to send to people who couldn’t attend. Maybe a coffee/tea mug for remote attendees?
    • Chocolate.
    • Include remote attendees in promotional materials (videos, etc.)
    • Figure out some social activities that can be done remotely – would video karaoke work? Playing a game over video chat? (Step one, get everyone a Cards Against Humanity deck …)
  • Have one of the major semi-annual planning sessions entirely remote so people attending are getting 100% of the experience and not just the “camera at the back of the room.”
    • Such a meeting may be a challenge to organize, but no more challenge than an in-person meeting.
    • Send out remote-meeting swag and chocolate.
  • Find meaningful ways to include remote people for otherwise in-person meetings:
    • Have high quality two-way video and use online collaboration tools you can use for short to multi-day meetings.
    • Give remote attendees real jobs to do for the meeting — be an organizer, be the introducing presenter, help take notes & document, present or lead a planning session remotely, etc.
      • I’ve been able to help remotely by running the IRC channel that people at the event come to for information, etc. Similar things can be done with social media. This can be done live as a sort-of transcript of the session (“live blogging”).
      • Interview the remote attendees for broadcasts (audio & video).
    • Make all-day meetings, having remote people block out the time to attend from there.
      • If you have budget, offer to pay for the remote attendee to rent a day or two of meeting room space at a local co-working facility. They will then have a chance to interact with the interesting people at that facility, and gain some cachet for being cool enough that people all together physically in another location are making the effort to include them.
      • Write a letter to an employer, teacher, or family members explaining how valuable it is to have this person attend even remotely, and thanking those people for accommodating the remote attendee’s being in an all-day distance session.
    • Cover the meal(s) of the people attending remotely.
    • Have the people who cannot travel identify some items local to them to have produced as swag and sent to all the other people who are attending remotely or in person. Can’t come down from the mountain to attend? Send down something from the mountain for the people who can.
    • Sponsor a regional meeting location so that multiple people who are close enough to drive are able to get together and attend remotely via video from the same location.
      • For multi-day events, you could pick a single hotel for those people to stay at, pay for them to all have drinks and dinner together in the evening, etc.
  • Increase value of local meetups so people who want to have in-person interactions can do so.
  • Reach out to the people who don’t get to travel at all for 1×1 for discussions with people who do get to travel — chatting over the phone or video every month or so to give a personal interaction.
    • Collect a few stories at the event that you know will be interesting or meaningful for those who cannot be there, then call that person directly and tell them about it. If someone comes by your booth and shares how much they appreciate or even have problems with a part of the project that someone not attending works on, make sure you are the proxy for that story to get right back to the remote person. Try to have a direct conversation instead of resorting to email. Initiating may be hard, some of us hate the phone, but it is a small discomfort if there is a reward of making a connection to what you missed out on.

The key is to realize that you need to put energy into the remote experience, not just save it all for the occasional travel-to event.

(Hat tip to Josh Berkus for some of the points on the benefits list. Thanks to all the people who have made it possible for me to attend something remotely when I couldn’t be there in person.)

EPEL round table at FOSDEM 2016


As a follow-up to last year’s literally-a-discussion-in-the-hallway about EPEL with a few dozen folks at FOSDEM 2015, we’re doing a round table discussion with some of the same people and similar topics this Sunday at FOSDEM, “Wither EPEL? Harvesting the next generation of software for the enterprise” in the distro devroom. As a treat, Stephen Smoogen will be moderating the panel; Smooge is not only a long-time Fedora and CentOS contributor, he is one of us who started EPEL a decade ago.

If you are an EPEL user (for whatever operating system), a packager, an upstream project member who wants to see your software in EPEL, a hardware enthusiast wanting to see builds for your favorite architecture, etc. … you are welcome to join us. We’ll have plenty of time for questions and issues from the audience.

The trick is that EPEL is useful or crucial for a number of the projects now releasing on top of CentOS via the special interest group process (SIGs provide their community newer software on the slow-and-steady CentOS Linux.) This means EPEL is essential for work happening inside of the CentOS Project, but it remains a third-party repository. Figuring out all of the details of working together across the Fedora and CentOS projects is important for both communities.

Hope to see you there!

Open source curriculum at Idea Fab Labs


Recently I’ve begun volunteering at Idea Fab Labs here in Santa Cruz, with two specific goals — expanding the space to include free/open source software ethos and hacking, and helping all these awesome makers with questions and reality around the open source way.

Tip — I got quite fired-up to do this from Ruth Suehle’s keynote at SCALE this year, so go watch that if you need any reason why you should be helping maker spaces and friends with your open sourcery.

On the first goal, I’m working up a space in the fab labs — similar to the 3D printing, CNC router, laser cutter, jewelry zone, electronics, etc. spaces — goal is to have a place to drop in and do real software hacking; teach others from the bottom all the way up on how and why to contribute; or, yeah, even freaking care about open source software.

Tip — if you live in the 21st century and care about the progress of technology, you should freaking care.

One of my many strategic plans is to launch a curriculum that we deliver 1x to 2x a month (year one), growing toward 2x to 4x a month (i.e., every week maybe!)

What do you think of these topic ideas as a way to introduce free/open source software to a local community that is technical, maker-oriented, but full of questions?

  • “What is open source?” — Basic explanation of what free/open source software is for all audiences.
  • “How do I fix this open source thing?” — You are using free/open source software in some way and have discovered something you wish to fix, report, or comment on, but … how do you do that? 1 hour class covers basics in 15 minutes, then dives in to two or three specific projects as examples.
  • “What are open source alternatives to My Favorite Software?” — You have some reason you MUST use N software from M vendor, but maybe something else will work as well?
  • “How do I use X open source software to accomplish Y?” — You want to learn how a specific tool such as GIMP, Inkscape, Blender, Krita, LibreOffice (OpenOffice), etc., might work for your need.
  • “Open source and your business – practical answers to practical questions” — You are wondering how people make money on this ‘free’ stuff. AKA, no-cost does not mean no-money.
  • “Avoiding open washing — following the open source way beyond software” — Open movements are everywhere, but are they all equal and give the same essential freedoms as free/open source software?
  • “How do I start an open source-like contribution community?” — You are ready to start a project of some kind, such as software but maybe maker-CAD-files or farm equipment or whatever. Practical step-by-step guide to be successful.

Thanks for your thoughts, my local peeps in Santa Cruz will really benefit. 🙂 Of course, all materials I write will be released under a Creative Commons license as part of The Open Source Way.

Update on CentOS GSoC 2015


Here’s an update on the CentOS Project Google Summer of Code for 2015 posted on the CentOS Seven blog:

This might be of interest to the Fedora Project community, so I’m pushing my own reference here to appear on the Fedora Planet. Much of the work happening in the CentOS GSoC effort may be useful as-is or as elements within Fedora work. (In at least one case, the RootFS build factory for Arm, the work is also happening partially in Fedora, so it’s a triple-win.)

Kimchi recipe


After making kimchi (or kimchee if you prefer) as a group with our Fairytale Farm interns, I got asked by one of them for the recipe. As is my standard mode, I want to release my recipes as free content, so I’m writing it up here first, then will link it out to All The Places. (I have to recommend working with a group or at least one other person, when you can — we did more massaging of the ingredients than I usually do, and it gave out almost enough liquid that I only had to add one-plus cup of water to each gallon.)

You may want to read more about sauerkraut and lactic-acid fermentation, as well as about kimchi itself. It’s really fascinating. One tip I have is that I choose not to “backsplash”, which is the term I’ve heard for the practice of pouring some of the liquid from an existing fermentation in to the new fermentation. Some people do this by using the fermented whey they get from hanging yogurt. I’ve found that I don’t like the texture and flavor when the fermentation is cut short in that way. In lactic-acid fermentation, there are several stages of fermentation that can only occur when you work up from just raw vegetables and salt. Backsplashing results in jumping ahead to the later fermentation stages. However, I often to backslpash after the fermentation is complete, so as to carry on the microbiotic benefits of the previous generation.

In this recipe I’m going to specify things by a single unit — one head of cabbage, one carrot, etc. My usual recipe would be about a 4x to 6x of the below, which would make about 1.5 or 2 gallons. The challenge is that a cabbage head or an onion is not a consistent size, so you have to gird your loins a bit and make some guesstimates in the end. That is, it’s not a cake recipe measured by weight at sea level in the south of France.

  • One tablespoon of salt.
    • I use Himalayan pink salt because
  • One medium to large head of napa cabbage
  • One medium carrot [per head of cabbage]
  • One-half to a whole a medium yellow onion (you may use more onion) [per head of cabbage]
  • One chunk of ginger the size of two cloves of garlic [per head of cabbage]
  • Two cloves of garlic [per head of cabbage]
  • One chunk of fresh turmeric the size of one clove of garlic [per head of cabbage]
  • Ground sweet to hot peppers of various types (paprika, mild chili, chipotle, and cayenne/african bird pepper/etc.) — adjust amount to taste but don’t put too much overpowering hot peppers in, unless you like that sort of thing
    • Per head of cabbage try a mix such as this:
      • 1 teaspoon sweet paprika
      • 1/2 teaspoon chipotle
      • 1/2 teaspoon mild chili
      • 1/8 teaspoon cayenne or hotter
  • Fresh ground black pepper (just keep grinding, but if you want an amount, at least 1/8 teaspoon per head of cabbage)
  • One teaspoon fish sauce or soy sauce (wheat free tamari is what I use) or neither
    • I usually make mine without fish or soy sauce so that it appeals to the widest diets, but for my own personal kimchi I put in lots of fish sauce.
    • Tip: wait to put these ingredients in until after the main lactic-acid fermentation is pretty complete, as fish and soy sauce are both fermentations and may change the fermentation process.

Start by cutting napa cabbage into squares roughly 1/2″ x 1/2″ (1cm x 1cm), larger for the greener parts is fine. Put in large stainless steel or glass bowl. Throw in salt, mix and mash and squeeze and mix to get the salt to integrate with the cabbage and start pulling water from the cabbage. Let sit while you work the rest of the ingredients.

Smash the ginger with the side of a knife to pound the fibers flat, then coarsely chop and put in a food processor. Do the same with the garlic and turmeric. There is no need to peel the ginger or turmeric (but definitely peel the garlic.) Pulse in the food processor until finely chopped. (You can do all this by hand if you prefer … sore hands.) Dump contents in to the bowl of cabbage, scraping the food processor with a rubber/silicone spatula.

Grate carrot on largest setting. I actually prefer a fine matchstick size from a vegetable mandoline, but you may use a cheese grater as long as you get the size up to pretty big. If your carrot is shredded fine it will dissolve too easily, become mushy quickly, and never be a nice crunchy pickle texture.

Cut both ends off the onion and peel, then slice in half from one end to the other. This leaves the fibers mainly intact so the juices remain in each sliver. Set the onion cut-side down, then cut half moon slivers working over the arc of the onion. (This WikiHow onion cutting techniques article has a good example as method one “Slice”.) Put the slices in the bowl with the cabbage. Don’t worry if you cut the wrong way or too large, it will work fine just be crunchier or softer in the end depending.

Toss in the chili powder mix.

Mix and smash and squeeze and pound and mix and mix. Mix some more. The more work you do here, the faster it will give out liquid, which helps you get a more compact (less dilute) brine.

You can let this sit in the bowl from 1 to 24 hours. When you are ready to set things up for proper fermentation, stuff the ingredients in to one or more quart-size wide mouth canning jar(s). Push contents down tightly, trying to cover with the liquid. If there is not enough liquid, which is common, add filtered (non-chlorinated) water to just cover the vegetables. (Chlorine in the water will kill some of the bacteria and other microbes you want to be present for flavor and pickling.)

Sit the jar on the counter in your kitchen, it doesn’t need to be in the dark. You can leave it uncovered (which may introduce other microbiotics that can improve or change the flavor or texture. Experiment with loosely covering if you want to see the difference.) If you have very active fermentation it might bubble over, so you can put a plate or tray underneath the jar(s). Taste and chew a piece of cabbage each day so you can experience the transformation. Use a the flat-side of a fork or spoon to push the vegetables back in to the liquid once or twice a day — you want the vegetables to pickle rather than ‘rot’ in the air (i.e. be broken down by enzymatic action instead of lactic fermentation.)

It should be ready to put in the fridge between day 4 and day 7, depending on your weather conditions. I’ve never found that I need to “bury it in the ground for six months”, but I can see how letting it ferment more slowly (such as in a cool basement/cellar) would help it keep longer without refrigeration.

Try variations of adding in about 20% other leafy green, such as kale or my favorite, Chinese mustard greens.

SCALE 13x – no talking, all walking, and a great ally skills workshop


For the first time in-I-can’t-remember I didn’t submit a talk to SCALE, so it was with a different personal energy that I attended SCALE 13x on 19 to 22 February this year. Not having a do-or-die public-speaking-scheduled-thing in front of me allowed for a more relaxed state of mind. Yet it was strange to not be one of the speakers this time. Still, all my old SCALE friends made me feel very welcome and accommodated. As usual, it was nice to have my family there, where so many know them as former speakers and regular attendees.

Rather than focus on talking to an audience, this time I spent my energy walking around the expo hall-and-wherever to talk with as many projects and companies as possible. My goal was to get an idea of who uses CentOS Linux, for what purposes, and get ideas of what people need and want from the project. I also provided information on what the Project has been up to especially around SIGs. That activity was fun, informative, and interesting.

Also I spent my share of time at the booth that housed the CentOS Project, RDO/OpenStack, oVirt, and OpenShift Origin. (I can’t wait to see the next iterations of Ryan’s Raspberry Pi 2 mini-cluster demo for OpenShift Origin.) I watched other people, including my wife, play with instruments and music software at the ever-popular Fedora Project booth (winners once again of a favorite booth award.) With a small rock concert and 3D printer, it was hard not to notice.

There were two sessions I was drawn to the most. The first was Ruth Suehle‘s keynote on Sunday morning, Makers:  The Next Frontier for Open Source. I’ve worked with Ruth a long time, seen her speak multiple times, seen lots of cool stuff that she’s made over the years, and I knew it would be an excellent talk. She used her great bully pulpit to teach and entreat the audience about the needs of the makers communities to get some serious clue and help from open source communities.

The other session was a workshop on Friday to learn skills as a man to be an ally for women when sexist things happen. This is something I’m interested in, being a better ally for people, including in the face of sexism and sexist behavior. For myself, I’ve begun calling myself a born again feminist. To me that means I’ve had a later-in-life realization that while I’ve always supported the ideas and topics around feminism, I wasn’t really aware how deeply pervasive sexism is, how blandly I’d looked past it, and that I could be part of the solution. Part of being part of the solution is not being afraid of being a feminist in name and action.

The workshop (described in detail here) was lead by Valerie Aurora, who’s gone from kernel hacker to executive director of the Ada Initiative. The Ada Initiative “supports women in open technology and culture …” Thus the workshop was primarily for people working in open technology and open culture. It started with a brief introduction that was useful in many ways, such as reminding us about how to best engage with difficult online exchanges (more advanced than ‘don’t feed the trolls’), the reason for needing male allies (hint:  it’s about doing something good with the privileged position and power that one has in society), and keeping it all in a useful context by not having the workshop be a place to debate “is there sexism?” Instead we acknowledge there is something broken, it needs fixing, and we here can do something about it. You can watch an introduction and highlights of the workshop in this video that Valerie gave to the staff at the Wikimedia Foundation, with closed captioned subtitles available for English.

For the majority of the workshop, we were in small groups (4 to 6 people) to discuss approaches we would take to certain scenarios. One scenario (as I recall them) was, “A woman is standing outside of your group at an event and looks as if she might be interested in joining the discussion. How would you handle this?” Another was, “At a work party someone comments that a co-worker with a large number of children must get a lot of sex.” Then the small groups discussed our approaches, and presented some ideas or questions back to the overall group. And then on to the next scenario.

The discussion/collaboration session was really useful in a number of ways. First, it helped give specific and general ideas of how to handle — and not handle — specific scenarios. Second, it also served to give a crosscut of different types of situations that do occur, so you can take skills from one scenario more easily in to another. Not only was it useful for dealing with sexist situations, it was easy to see the same thinking and skills could be applied to any situation where someone is objectified, made to be an Other, treated as a stereotype, and so forth — thus useful for handling racism, ageism, and so forth. Third, it was useful to get a chance to practice what to say in response when we witness sexism, partially because it’s helps us to have something to immediately say rather than being shocked and mute.

The format of the workshop was great. Elements included working in small groups, a person in each group being a gatekeeper who makes sure everyone in the group is heard from, presenting ideas back to the overall group in a discussion format, all the way down to how we introduced ourselves to our small groups. I also appreciated moving across groups at least once, that helped us get fresher perspectives with each scenario.

This is definitely a workshop I’d like to bring to any tech company. All of us can use help and perspective on how to react when someone does something sexist, or we have a chance to do something about systemic sexism. We can agree that it’s unkind to make people feel uncomfortable, and it’s kind to help people by pushing against the discomfort making.

There is something I’ve noticed for most of my life. When talking with my peers — people who are born mainly after the 1960s in a post-feminist-creation era – we are often in agreement about how people should treat each other along the axes of sex, race, gender, and so forth. And while I see in younger generations a huge amount of support for ideas such as “people should be able to legally marry whomever they want”, I still hear a lot of people afraid of the f-word — feminism. It’s as if people are in full agreement with the concepts behind the word, but afraid to use the word itself. This is the other part of my ‘born again’ experience, that I need to embrace the word as well as the concept in order to really align myself correctly, live correctly, and be a good ally of all people.

And now a few words from Paul C.


Although some people in open source communities might not be aware of him, Paul Cormier holds a singular position in the open source world. This hinges on the detail that Red Hat is the longest standing and most successful company at promoting the growth of free/open source software and especially the acceptance of that software in the enterprise (large businesses.) Paul is a Red Hat EVP, but he is also the President of Products and Technologies, meaning he is ultimately accountable for what Red Hat does in creating products the open source way. Paul has held this position essentially for the last dozen years, and so has overseen everything in Red Hat from the creation of Fedora Linux to the rise of cloud computing that Red Hat is an intimate part of.

In other words, when Paul C. speaks — keynote or in-person — he is someone really worth paying close attention to.

In this post on Red Hat’s open source community website, “One Year Later:  Paul Cormier on Red Hat and the CentOS Project“, I provide some introduction and background around a video interview Paul did with ServerWatch about the Red Hat and CentOS Project relationship.

(Speaking of ‘intimately’, that explains my relationship to Red Hat and the CentOS Project — I spent all of 2013 architecting and delivering on making CentOS Linux the third leg in the stool of Red Hat platform technologies. When I say in the “One Year Later…” article about “making sure (Paul C. is) happy and excited about Red Hat joining forces with the CentOS Project,” that responsibility is largely mine.)