And I’ve watched communities I love burn through their best contributors because they couldn’t figure out when not to do everything in public.

This is the thing we don’t talk about enough.

There’s a common belief in open source that radical transparency is an unconditional good. Everything logged. Everything archived. Every decision made on a public list where anyone can read it, respond to it, and screenshot it for later use. The argument is intuitive: sunlight is the best disinfectant. Transparency protects against power consolidation and secrecy. Leadership is a performance art.

I’ve said that last one myself. I still believe it.

But I’ve also seen what happens when transparency becomes an ideology rather than a tool. When communities treat any private conversation as inherently suspect. When good contributors get publicly savaged for decisions that were more complicated than the hot-takes acknowledged, and then quietly stop contributing. When conflicts that needed careful, private handling got aired in front of a live audience and never actually resolved. When every governance discussion became a performance of who was most righteous, rather than an honest attempt to work something out.

Radical transparency doesn’t always produce radical honesty. Sometimes it produces theater.

Here’s what I mean. Sit in enough governance calls, read enough mailing list threads. You start to notice: the real deliberation has already happened somewhere else. What you’re watching is the 90% solution, brought forward for discussion and socialization. Because people don’t air genuine uncertainty in front of an audience of hundreds. They don’t say “I’m not sure this is right” in a space where that gets archived and weaponized later. So they wait until they’re confident, or until they’ve built enough private consensus to feel safe. Then they show up to the public forum having already decided.

This is what transparency absolutism produces: it doesn’t eliminate private deliberation, it just denies what is happening and makes it invisible. The actual decision-making retreats into DMs, off-list email, hallway conversations at conferences not everyone can afford to attend. If we want governance that’s genuinely accountable, we need to be honest about which conversations require privacy to function — and then design those spaces intentionally.

There is a human cost to the public forum which we consistently undercount.

I have watched thoughtful, skilled, generous contributors leave communities after being publicly piled on for a governance decision that had more context than the audience was given. I’ve watched people self-censor for years. Too many people never raise a concern, never flag a problem because they have seen what happened to someone who did. The communities that proclaim most loudly their commitment to openness are sometimes the most hostile to honest dissent, because every disagreement becomes a public performance.

This hits hardest for people already navigating the most social friction to be in the room. Psychological safety, the ability to take an interpersonal risk without fear of punishment, isn’t a soft concept. Isn’t evenly distributed.  And, it’s a prerequisite for honest participation.  You can’t build it in a fully public forum.

So what private spaces are actually legitimate? I’m not arguing for back rooms and opacity. I’m arguing for intentional design. Here’s how I think about it.

Code of conduct and conflict resolution. This one is non-negotiable. When someone files a harassment or CoC complaint, that process has to be confidential. This confidentiality is not to protect bad actors, but to protect reporters. The same legal and privacy obligations that govern HR processes exist for a reason, and they apply with even more force in volunteer communities where people have no institutional protection. Public trials produce performance and permanent record, not resolution. The community should know a process exists, how it works, and what outcomes are possible — without transparency into individual cases.

Leadership deliberation before public proposals. There’s a meaningful difference between a decision being made privately and a proposal being developed privately before it comes to the community for real input. Leaders need to be able to think out loud, explore bad ideas without them becoming permanent positions, and build enough shared understanding to make a coherent proposal. If every half-formed thought must be aired immediately, the thinking that happens in public gets shallow and performative; the real thinking moves somewhere less visible. The guardrail: deliberation may be private, but decisions must be public and subject to genuine input. The community must have a real opportunity to change the outcome.

Sensitive personnel and employment matters. This is the category open source communities handle most badly, because we weren’t designed for it. When a maintainer’s behavior creates a problem and the full context involves their employer, their personal circumstances, or information shared in confidence, there is no good public path. The community gets asked to make a decision without the information it needs. Or the relevant parties get asked to expose things that shouldn’t be public. Or the problem festers because no one wants to touch it. Mature governance requires a small, trusted group or ombudsperson function which can hold this information and make decisions with full context.

Mentorship and next-generation leadership. This is the most politically sensitive, because it touches the nerve of insider access. But I’ll argue for it anyway. When community leaders are deciding who to invest significant time in — who gets mentored, who gets nominated, who gets an introduction to a key person — those conversations benefit from a private space where honest assessments can be made. The alternative is that sponsorship happens entirely on informal vibes (the hallway track), or it becomes performatively positive because everything is public. Neither actually serves the goal of building a diverse, capable next generation of leadership. The accountability check here is outcomes: does the group being invested in reflect the community’s diversity goals? Is the process documented well enough to evaluate over time?

Psychological support offers. Lots of community members handle situations of psychological stress up to burn out. Individuals feel overwhelmed by the expectations and the pressure to deliver a product like quality without having even nominal corporate support structures. This situation is common but is often internalized as individual failure or worse, leads to isolation and compounding negative experiences. Normalizing project level conversations of this stress and developing community practices for support and coping is important. However, individual needs must be handled privately as this kind of problem can still stigmatize and may have second order impact on families, careers and even health insurance.

Across all of these, I see three things that separate legitimate private spaces from back-room cabals.

Transparency of process, not content. The community should know the space exists, what its scope is, who is in it, and how decisions made there feed back into public accountability. Secrecy about the existence of a space is very different from confidentiality about its contents.

Defined scope. Private spaces need explicit charters: this group handles X, not Y. This deliberation is private until a proposal is ready, then the outcome is public. Spaces without defined scope expand until they’ve consumed everything.

Diverse, accountable membership. The people in the room should reflect the community’s diversity goals, and they should be accountable to the community — through term limits, rotation, recall mechanisms. A private space staffed by the same five people indefinitely is a cabal. A private space with rotating membership and clear accountability is a committee.

Transparency is a tool. It’s in service of deeper values: accountability, fairness, the ability for every contributor to participate on equal terms. When transparency undermines those values — when it produces performative governance, drives out vulnerable contributors, and forces sensitive matters into the worst possible public forums — we’ve confused the tool for the goal.

The communities I’ve seen govern themselves well are honest about this. They didn’t pretend everything could or should happen in public. They designed their private spaces carefully, named them, gave them appropriate scope, built in accountability, and brought outcomes back into the light.

The goal was never a community where nothing is private. The goal was a community where what’s private is private for good reasons — and everyone knows what those reasons are.

That’s worth building.

Postscript: I’m currently studying in the Political Science department at Trinity College Dublin, applying social data analysis to questions about technological sovereignty and trust. One of the things that’s become clearer to me through that work is that open source communities aren’t some novel invention — they’re governance structures, with all the same failure modes and design challenges that political theorists have been writing about for centuries. The tension between transparency and deliberation isn’t unique to discussions on GitHub.

James Madison argued against public deliberation at the Constitutional Convention specifically because it hardened positions and prevented agreement — the framers of the US Constitution held their deliberations in secret for exactly the reasons I’m describing here. Jürgen Habermas, whose work on the public sphere is often invoked to defend radical transparency, actually argued that publicity is a necessary feature of outcomes and legitimacy, not of every stage of deliberation.

A Brookings piece published recently makes the same argument in a governmental context and is worth reading alongside this one. We in open source tend to think we’re solving new problems. Often we’re rediscovering old ones. That’s not a criticism — it means there’s centuries of prior art worth reading.

Sarah Novotny has worked in open source community governance for two decades, including Kubernetes, OpenTelemetry, NGINX, and MySQL. She currently lives in Dublin and is studying political science at Trinity College.

I’m going to make an argument that humans are not built to live and work the way we do today. We have not evolved far enough to comfortably exist in our modern context. There is a whole lot of information coming toward us every day and not a lot of direct, deep social engagement. And, even less physically proximate social engagement.

About twenty five years ago Robert Putnam wrote a book called Bowling Alone. This book focused on the US and talks about the lack of social connectedness that continues to manifest in interesting ways.  His title speaks to one example of bowling leagues.  More broadly, the missing element of third places. Now the idea of the third place is a park or a public social area or any convening group or location.  Broadly speaking he is addressing non-work social groups that bring people together in order to move towards some sort of good. Other examples were neighborhood socials, schools & churches, affinity groups and Rotary International.This sort of non-work, non-family social construct has been disappearing as we have been doing more and more things online – getting our services, our recommendations and our engagement with the world at scale and online.

Where I believe this breakdown is most visible is in the concept of trust.  Greater trust between people could actually help us improve not only our happiness and engagement in the world, but also allow us to build better, healthier businesses.

Because I’m a nerd, I always start with definitions. So for today’s talk, I’m gonna narrow Trust down to a belief in the reliability, truth, or ability of someone or something.  So that’s both as a noun and as a verb.

The very simplest case of building trust is two people. Usually, we build trust between people. In this case, Alice trusts Bob, and Bob trusts Alice.

Now there’s also a concept of transitive trust. Where Alice trusts Bob, Bob trusts Alice, but Bob and Carol trust each other as well. When Bob introduces Alice to Carol he offers this transitive trust. You’ve done this anytime you’ve made an introduction for someone.This is a use of transitive trust. Hey, I love you both. I think you should work together.

So this is super important in building these mutually reliable and engaged groups and communities and pairings and partners. Again, mutual reliability, truth, and ability. Now how do you actually foster this intentionally? There are several techniques I use. One of them is fairly straightforward.  Be vulnerable and authentic. I am myself and no one else here on this stage. I’m gonna stumble over my words, I will make nerdy jokes. And I’m gonna tell you some stories about me and my life.

One of the ways that I see trust being undermined most recently is by sharing misinformation.

People are frequently engaging with things that are not necessarily trustworthy and sharing them on, offering that transitive trust that we talked about between Alice, Bob, and Carol. Now in this image, Bob is offering information that he saw that he trusts. As he offers this piece of information he has unintentionally offered that transitive trust. Now here’s a funny story. My partner and I trade links and articles back and forth all day long. He is one of my highly trusted views into the world, and he sees things and notices things I don’t because his perception of the world is very different from mine.

There was a moment several months ago where he sent me a link to something and because I trust him, I trusted that link and I trusted that piece of information -without thinking critically about it.   About fifteen minutes later, he texted me again saying “I’m so sorry. That was bad information. Here is the right information”. By that point, I had already shared with other people I knew this really pertinent piece of information that caused my limbic system to react, and that shortcut to belief is how we see so much misinformation being shared today. So this hijack of our trust through information and influencers online, other entities that want to get you to share their message, that is something that is incredibly important and is starting to break down the way we trust in the world today.

Now we are rewarded online for some of these behaviors. There’s a sense of people in the know, out of the know. But the hijacking of trust and the use of social media to share information in this high volatility, high value way for someone who maybe has the first scoop of information. That is one of those spaces where we’re starting to undermine trust.

I framed basic trust as between two people or a person and a group of people.  However, there are nonhuman things that we trust. We trust our senses to give us information and maybe our senses can give us bad info.  We trust organizations. We trust a hierarchy in our businesses. We trust cars to drive us from place to place. We trust technology to make sure our bank accounts are correct. So there is trust in things that are nonhuman, but they’re just tools. That distinction makes the trust a little bit different.

We’ve been trusting and talking about trust a lot in the last twenty years in the tech industry. Because the cloud brought us something that was super different as far as how we trust in the world. My friend,Mike Bursell, wrote this amazing book “trust in computer systems and the cloud”, and it really clarified for me how much trust we put into a single bit of software and that that software will behave as we expected.

So this is a great example using the same alphabetical notation that I did earlier for Alice, Bob, and Carol. But now we have   “company a deploying software from provider b using libraries from open source community c and proprietary software provider d” . My favorite line in this entire book is “we realize that we are already halfway through the alphabet and have yet to consider any of the humans in the mix”

Now I did promise that this talk would have more AI in it. So I’m gonna start with the concept of generated AI here. Generative  AI is fascinating and fun and exciting to play with, and it is a statistical prediction model.  I’ve quipped “T9 v 4.0”.

Now AI broadly does lots of really interesting things. And we can learn to trust these tools over time. But part of what we really need to focus on is how that trust is contextualized.

So do I want to attend an AI generated talk about trust? No. In fact, if you look back up at my abstract, the abstract was written by an LLM. I I figured I’d play with it and I’d see what happened to put something up on the conference page to make sure that I had a bit of content in the program catalog as needed. But it’s really bland and it’s really boring and it doesn’t sound like me or share any of my authenticity.

So we have this whole new set of tools that we get to use to build things. And those tools may make us be able to work faster and if used improperly, they may help us break down trust. There are lots of other things they’ll get to help us do as well, but those are the two that I’m thinking about right now. So how do we trust tools? Like, this is an example here with a crowbar. It’s an example of a simple machine, a lever.

Levers are incredibly useful for all sorts of things. But I guess my question would be, “would I trust this tool to wash my window?”

No. I really wouldn’t because that’s not the context in which it should be used. So I need to always think in terms of the context of the tool and how you’re using it. So for generative AI, there is a context and a setting for when it’s incredibly useful and incredibly powerful. And then there’s a context where it’s exactly the wrong tool.

In those wrong cases, you end up with content or product or interactions with other people in your teams that destroy trust. It is the same with all tools, and ways to build a new world with them, build a faster world with them. There is also the possibility for tech to become something that Dan Davies calls an accountability sink. There was a great comedy clip from The UK in, the nineties –

someone was trying to answer questions of a customer and the only answer was “the computer says no.” “The computer says no.”

There was no ability for that person to make changes. The computer said no. That was the end of the conversation. And there was no accountability for this “no” because it wasn’t the clerk’s fault. The clerk was very clearly just using the tool in front of them to answer the question.

That is an accountability sink. It separates the person who is answering the question from the accountability of bringing back a good answer.  Anyone who has tried to change a flight or get an answer as to why a flight was canceled or try to do something that is just a little bit outside the statistical norm has found tools sometimes just stop won’t let you move forward. Your tools say that doesn’t work,that can’t happen, And there’s no accountability for this problem not being solved.  So we have to be really careful to avoid these broken promises, these broken pieces of trust that are technological accountability sinks..

This is the big question at this point. How do we resolve this? And, honestly, as much as I think about this, I think about ways to build community and strengthen the teams that I am working in. The only suitable tool I can find is the human investment of time. Because “at scale” is one of the scariest phrases I know. In that, we’ve tried to supplant trusting humans with trust in brands or trust in tools. Now, again, this can work, but there has to be a feedback mechanism to make sure that the people who are having issues or the issues that are happening outside of the average experience.

The problems that are happening outside of that or the humans that look different from the average the software was built for –  they need to be served too. And in order to build that mutual reliability, truth, and ability that we talked about before, we have to have feedback machines. We have to have ways to bring feedback into all of these new tools. So that investment of human time is both important for building the trust that you have between humans. And also building the feedback loop for when these tools around us break or give bad information. We need to fall back to the old model of human trust.  Built by the human investment of time.

So here are some suggestions for human investment of time. Let’s first put down any technology that is not facilitating the conversation at the moment. Spend time connecting deeply with people. That could be long written letters as we saw in decades and centuries past that could be phone calls and conversations. That could be video calls. It’s possible. It may even be interactions on social media, but just check them to make sure that what you’re having is a conversation and what you’re building is mutual trust as opposed to a parasocial relationship where you feel like you are being heard and understood by someone who does not know you. Parasocial relationships are a catalyst for people who tend to become disenfranchised and step away from their interconnectedness in their communities.

Another example or effort that may help you is to really slow down. I know it feels crazy to say slow down in the world that’s moving so quickly today and to feel as if the AI powered revolution is getting away from you again and again and again.  Maybe it’s timeboxing  – I’m going to not work at speed or I’m going to do something very slow and methodical and good for me, two hours a day, one hour a day, several hours a week. I’m focused on the  kids. I’m going to spend time with them in person. Whatever that looks like, slow down and enjoy the humans for who they are. In order to be able to go faster when you need to nurture you and your relationships.

Another suggestion is to make sure that you are spending time in nontraditional or non similar spaces. So if you are trying to grow trust with your team and you always and only see them at work, try to find some social space to connect with them or take a walking one on one or meet people out in the world. Engage with them as whole humans as opposed to simply heads in a in a video conference.

And then my last direct suggestion is one that has pulled humans together for millennia. Which is eating together. Now this is not always possible in our very connected world where I might be talking to someone from bars from here in Barcelona talking to someone in Seattle, or taking, you know, taking early and late night meetings but you can do this. Let’s invite each other to share time with tea, and you bring your tea and you tell each other about your tea. And you have a connection and a little bit more of a a human space, made by handling the necessity of eating and drinking.

Today, people are connected in all sorts of ways.  As I said, we’re sometimes connected very virtually from other ends of the globe. Some we’re connected very locally.Sometimes you are in chosen groups. Sometimes you are in corporate groups. Or affinity groups. You may exist in any number of these relationships. Maybe you’re an end node in a graph that isn’t very connected. Or maybe you’re someone connected to two very deeply connected to two distinct graphs. All of these are great, and any work you put into this will make your connectedness better, deeper, and ultimately will allow you to engage more authentically with these people at a higher level of trust and and with higher expectations.

Building and nurturing trusting teams really brings us stronger, more interconnected teams, resilient teams that do better with better with hardship in front of them. Or hardship around them and still produce greater business impact.

Studies also find that connected and trusting humans are generally happier humans that have greater business impact. There’s a great study from Harvard that’s been following people for eighty years.  And it really does show that people are happier with that sense of place and well-being in a community, whether that community is your corporate team, or an open source project or a social group you’re part of or an intramural sport you play, These connections are what build happier humans and bigger business impact.

References

Bowling Alone by Robert D. Putnam

The Unaccountability Machine by Dan Davies

Trust in Computer Systems and the Cloud – Mike Bursell

Harvard Happiness Study

“The task of assessing the trustworthiness of open-source (OSS) that is in use, or that is being considered for use, is more complex for OSS than for proprietary software, because there is, generally speaking, no direct relationship between the authors of software and those who use that software.”

— Aeva Black, Section Chief, Open-Source Software Security at CISA

I have long observed that companies reliant on open-source software—which today includes nearly all of you—neglect their investment in open-source security processes. These processes must include continual engagement with information about project changes and internal accountability. Advocating for intentional project participation and corporate accountability measures should be paired with vigilant remediation of open-source dependencies. Together, these efforts ensure we manage and communicate security issues inside open-source projects and our companies in the best way possible, in line with industry best practices and embargoes.

Vulnerabilities of Under-Resourced Open-Source Projects

In addressing enterprises’ responsibilities within the open-source software landscape, I advocate for a pragmatic approach grounded in real-world experiences. Know what your dependencies are, remain informed about those projects, and ensure the software’s maintainers are well-resourced (or you are willing to take on that effort). Recent security incidents, such as the notable XZ backdoor, illustrate the vulnerabilities of under-resourced projects to social engineering tactics, particularly when disguised as assistance. Many popular projects, often operated by just a handful of maintainers, strive to meet the extensive demands of commercially used software. Unfortunately, we frequently observe predictable outcomes from such scenarios.

The XZ backdoor example highlights the critical need for sustained investment by open-source consumers—like your $software_company¹—in proper governance and shared responsibility across your extensive open-source project dependencies.

Note: The XZ exploit, identified as CVE-2024-3094, involved a sophisticated backdoor inserted into the XZ Utils compression library by a maintainer under the guise of “Jia Tan.” They added this backdoor intricately to the build process rather than the source code, complicating detection. It exploited the IFUNC mechanism of glibc to manipulate SSH authentication, impacting several Linux distributions. The exploit underscores critical vulnerabilities in the open-source software supply chain, highlighting the importance of rigorous security practices.

Catalog Your Dependencies and Their Security Changes

The first pressing issue in enterprise open-source strategies is managing dependencies and their security changes. Currently, enterprises struggle to track both internally developed dependencies and those sourced from open-source. Unfortunately, there are no simple solutions to this problem.

A critical security responsibility is thoroughly understanding the open-source components used within any custom software and any tooling used to produce it. Next, you need to remediate issues across your installation base. Monitor open-source security mailing lists and other resources, like the Common Vulnerability and Exploit (CVE) database, to stay informed about impactful vulnerabilities. This knowledge lets you promptly identify and update affected components ahead of and during a security incident.

You may even maintain a catalog of dependencies already. Traditionally, organizations have cataloged licenses for compliance. Expanding that practice from compliance to awareness of and engagement with those dependencies is important, enhancing security oversight.

You must actively participate in open-source projects on which your software relies. Understanding these projects’ ongoing changes and security measures is vital for your success. For instance, major tech companies like Google, Microsoft, and Amazon each actively engage in the Kubernetes community to support their products, GKE, Azure AKS, and Amazon EKS, respectively. Their ongoing and project-level involvement helps them stay abreast of security developments and contribute to collective safety efforts.

Onwards and Upwards, Open-Source Security, Here We Go

Security in open-source software continues to be an unattended problem we ignore—even though it’s certainly on our government’s radar. Honestly, we need to care more, too. 
To wrap up, I recommend reading the following article that dives into this topic: “Continued Progress Towards a Secure Open-Source Ecosystem,” by Aeva Black, who heads up Open-Source Software Security at CISA. It’s a great resource to learn more about what’s being done to safeguard our digital security infrastructure as a nation.

1. I still have a soft spot for Perl. ↩︎

When I joined this project and became part of this adventure, I knew that the tech industry wouldn’t change rapidly simply because Google said so. The paradigm shift from virtual machines to containers would only happen with the support, advocacy, and engagement of the broader software industry.  To accelerate this change, our efforts needed to focus on sharing the vision, drawing in contributors from lots of companies and making each individual’s role within the project impactful to them as well as our project.

Kubernetes is an open-source platform that automates the deployment and management of containerized applications, ensuring they run reliably. It handles tasks like scaling, self-healing, and load balancing, making it easier to keep your apps up and running smoothly.

Those words were repeated by me and an exponentially growing number of people in the first three years. Kubernetes went from a buzzword, to a chaotic scramble of community meetings, to a transformative force, thanks to the efforts of early believers. We built a powerhouse of a distributed project community, highlighting the software’s practical value of cloud portability to large enterprises and startups alike.

The community itself fueled this movement – a vibrant mix of individuals, each with unique strengths and passions. I fondly referred to the project as my “island of misfit toys”.  We collected unconventional thinkers and passionate problem-solvers who thrived when given the opportunity to contribute.

Magic happens when like-minded people find each other, but magic alone won’t sustain a project of this size. It was the intentional structuring and nurturing of community defined values in addition to the technology that truly propelled Kubernetes forward.

In the early Kubernetes community, we placed great importance on rewarding unglamorous work and developing project infrastructure that benefited everyone. In the same way, we promoted and rewarded  positive social behaviors and while actively discouraging negative ones. This wasn’t just about following rules; it was about fostering a culture of kindness and respect for each other and the future generations of maintainers. My vision was centered on good humanism, ensuring that everyone in the community acts with consideration and empathy towards each other and our shared future.

I have long observed (and emulated) that the best leadership approach starts with transparency and is focused on building. Leaders must embody a philosophy of openness and accountability. It’s not just about coming together; it’s about fostering a true sense of community where everyone lives and operates openly. The idea of public transparency in management and negotiation is crucial to me to avoid the failures of power consolidation and secrecy.  Leadership is a performance art.

Open collaboration and emergent leadership is more innovative and interesting than traditional top-down leadership, because it encourages spontaneous, self-organized participation, enabling diverse perspectives to surface and drive creative solutions. Open source isn’t just about code—it’s a mindset and a set of collaborative practices. By committing to openness early for the Kubernetes project, we empowered ourselves to build better software and a better experience for our consumers, which had the side effects of driving economic growth.

Building the Kubernetes community wasn’t just about creating a structure; it was about fostering a sense of belonging and purpose. We provided clear pathways for individuals to grow and lead, ensuring everyone felt valued and empowered to make a difference. By aligning personal growth with project goals, we cultivated a sense of identity and tribalism, where each member played a vital role in advancing our shared mission. We helped the “hand-raisers” define roles in the project and career paths within this nascent space of industry-wide collaboration, crossing corporate boundaries. We built a place where magic could thrive.

As we celebrate this milestone, let’s continue to embrace collaboration, empower individuals, and build a future where innovation knows no bounds.

#Kubernetes #CommunityEmpowerment #CloudNative #TechIndustry #10thAnniversary

September 11th 2014 I was diagnosed with breast cancer.

That Thursday morning, after I finished giving a talk, I took a call from my doctor and took the rest of the afternoon off. With that call, an ancillary characteristic of me became the focal point of my next 4 months.

Mammograms. Get them.  No, really, stop here and write yourself a note.

Because my cancer was caught early, I had the luxury of time to consider options… I scheduled my surgery 6 weeks out. Immediately after a conference I was planning.

Spoiler.  I’m lucky.  Extraordinarily lucky.

I chose a double mastectomy because the most important outcome for me was “event free survival”.  I was graced all the best possible outcomes.  The surgical pathology found nothing in my lymph nodes except tattoo ink. I needed no chemo; no radiation.

The struggle.  What is my identity?

But, what I want to talk about is the question I was asked most in both the lead up to surgery and post surgery. “Are you having an identity crisis?”

No, I’m not having an identity crisis. But, what do you mean by “my identity”? To me, this question presumed a lot about the value of women in society.  After all, no one asked me about my identity when i got my appendix out or when I broke my foot.

I am… No, really, what is my identity?

I am what I do.  How I contribute to the world. How I support my friends and my partner.  I am a thinker. I am a creator. I am a community member.  I am a supporter.  I am a traveler.

I am confused.

And everyone kept asking “Are you having an identity crisis?”

Suddenly, in spheres where I expected to be valued for my contribution i had to introduce conversations about my secondary sexual characteristics

How Would i know?

I continued to answer “No, i’m not having an identity crisis.  I went back to work 3 weeks after the surgery. I was actually *happier* with my shape than before the surgery. But, I couldn’t think.  I had no stamina. I had the attention span of a single crossword puzzle clue.

Who am I? Crap, I *am* having an identity crisis.

If I can’t write an articulate sentence, or i’m 3000 emails behind, or if I can’t meet a commitment I made …  Am I less? Am I me? What is my value?

Societal cues suck.

With my internal cues failing, I looked outside. But, I am not my shape or my bank account.  I am not only my accomplishments.  Media and peer groups amplify fears to persuade and control. Societal cues seem to support the voices in my head that said I wasn’t good enough.  Advertising suggests I *need* to purchase things to be smarter or prettier or stronger.  It supports my feelings of inadequacy and imposter syndrome.  “I’m not as smart as they are”.  “I’m not $measure as she is…”

Fear Manifest.  I’m not good enough.

When I was asked “Are you having an identity crisis?” I heard fears that my friends had bought into. Fears that our values were tied to specific characteristics.

I’m an adult struggling with this.  I have had years to evaluate and decide what I value in myself. And, yet, being asked “Are you having an identity crisis” challenged me.  What are we reflecting to the younger people around us. What about the next generations?  What are our biases teaching them? Can we stop them from absorbing our fears and societal expectations?

January 2015.

My brain returned, and I could see my stamina increasing.  Life began to return to normal. I could hold a conversation.  I could stay up past 6pm. I was 2 pounds closer to being a fierce skinny old lady.

I am changed.  And still prone to over commitment.  As I struggled with this identity question, my step father quippily reminded me that we are human be-ings not human do-ings.

I am.

Today, I try to treat myself as I would treat a friend. Valuing my be-ing without judgement even as what i do in the world changes.

this summer i decided to go looking for the next thing.  i did a lot of brainstorming and mind-mapping to find out what i wanted.  it turned out i wanted many things.  to those of you who know me well, this isn’t a surprise.  but it did present a bit of a problem.

seattle graffitti

i want to found a new company.  i have an idea or 10 but there are some skills that i’m lacking.  i considered starting a company anyway. recognizing that i’ll never know all i want  to know, i thought about it a lot.  ultimately, after a few weeks of conversations and lots of long hard thinking i decided i wanted to spend some time in a product company, first.

so, its official this is big transition time.

i’ve left the staff of BlueGecko after almost 11 years.  i’ll remain on the board and active in the MySQL community but my day-to-day work will only tangentially be related MySQL.  tomorrow i start a new role at Opscode i’ll begin by building their sales engineering team and learning Chef from soup to nuts.  I’ll get to spend time with customers trying to do product development and i’ll get to spent time with product people.

all this will move forward my skills in a new and exciting direction.  i can’t think of a better way to spend labor day than to consider my new opportunities and look excitedly to the empty frame of my next adventure.

for those of you who might be living in a cave or not on every oreilly media mailing list, ignite talks are a specific type of lightning talk. enlighten us, but make it quick is their tagline**.** 5 minutes, 20 slides, auto-advancing every 15 seconds. it’s usually spectacular or a spectacle.

this year i was able to mc the ignite talks at the 2011 MySQL C&E, will be giving an ignite talk on geek lifestyle at ignite seattle 14 on may 18th and then mcing and presenting at OSCON’s ignite show in july.

but, the things i’ve been mentioning to everyone over the last weeks as i describe how much i enjoy ignite talks are some of my favorite talks that from the last few years. so– here are my top 5 ignite talks:

1. why i love my 3d printer (and you will too) – Schuyler St. Leger
2. flashmob gone wrong – Tom Scott
3. the secret underground world of lego – Hillel Cooperman
4. lymphomartini – Tom Music (sadly, tom died from complications of his illness almost a week ago on 4/17/2011)
5. how to write 1000 words – Scott Berkun

i hope you enjoy and find an ignite show near you (there are more than 100 cities that have these events regularly).

1.  have a central theme

• creation of the mysql council
• why was this created.
• ioug saw opening and wanted to bridge between mysql/oracle

2.  talk in soundbites.

• a bit of tech jargon is ok
• concrete
• don’t use overly long analogies

3. don’t use this space for an ad

• deliver news
• be respectful of reporter and her goal of unbiased testament

4  answer or refer or followup

• reporter isn’t in total control
• ok to say I’d like to double-check or followup
• easy out – andy a better person to answer that question

5.  dead space is ok.

• reporter might be writing notes
• this can be a tactic to elicit unguarded ramblings

bonus: cheat, have the press release in front of you.

there are more than a few things that lead up to this including many things that were out of my control. but, the result of this was instead of a week off to sleep a ton and get over a basic headcold, i ended up having sinus surgery and taking an enforced 3 weeks off in september.

it was Alyssa Royce’s post naked in the board room this morning that made me resurrect this post  which i’d started it back when i was recovering from the surgery and had a bit of free time.  i was (and still am) unsure about the implications of publishing that i worked myself silly over the summer and worried about the message it gave my clients.  it’s now november; nothing awful happened, no one was terribly upset that i was out for 3 weeks, and i have a better sense that everyone gets sick.  no one expects me to be superhuman and i should just get over trying.

so, taking this to heart  even though i was in portland to participate in open sql camp last weekend, i decided to take the day off on sunday to wander and enjoy powells, powells tech, countermedia, and reading frenzy the city.  i still had a pang of “what am i missing? there is so much more i could be learning!”, but i’d talked to the people i wanted to and seen a few really interesting presentations and  i really wanted to walk around and be somewhere quieter than souk with 130 exuberant geeks abuzz about databases.  walking from bookstore to bookstore, kicking leaves and leafing through books is a great way to spend an afternoon

my point though is  – more balance, more short blog posts about things that interest me, more sticking my neck out, more authenticity.

oooh, and check out the uproariously funny noSQL glossary lightning talk by Brian Aker.

my background isn’t computer science, it’s physics. i was languishing in an phd program at unc when i first got introduced to networking, systems administration and databases. but, i wasn’t sure i wanted to make the switch. ultimately, instead of changing paths in school, i decided to leave and work at amazon.

it took me a long time to not see that diversion as a failing.

all that said, one of the first books i acquired to investigate this computer operations bent was “the red book” by evi nemeth. here was a super smart academic who was interested in and writing about things i was interested in (i’d had my full share of scattering papers).  i was so moved by someone who had achieved success (i.e. academic success) in this field, that i decided to explore more.   i pressed hard to move out of the group that was maintaining tools for amazon’s customer service group and be given an opportunity in infrastructure.

with that single opportunity and the fascination with evi’s book, i laid the foundation for my subsequent career path development. i took a leap into a world of books and computers.

maslow not withstanding, of course. does anyone need more to sustain them?

“the red book” has been released twice more since i first laid hands on it and it’s now “the purple book” and evi has retired, but i still credit her with being a beacon for me in a fog of indecision as i was trying to understand what to do with a dream (of being a physicist) that hadn’t ever been examined closely.

i’m super excited about the opportunity to speak as well as being invited to goto SF tomorrow to brainstorm at the velocity summit.  i’ll write something more after the summit if i don’t have to be too secret squirrel.

however, i’m stuck at the moment in a quandary that is entertaining for me.

if i am the partner that is responsible for and a technical contributor to our MySQL practice will i be the principal (as i was taught over-simplistically in elementary school  – the principal is your pal.  it’s a noun.) or the principle (a law or precept -again simplistic).

i don’t tend to think of myself as a law unto myself or the primary source, so spelling it principle doesn’t seem right. and the definition of principal of most important, consequential, or influential  is closer.  but, i’ve gotten feedback from clients that each is wrong. i can’t have it both ways or in this case, neither way.

i’m stumped.  i assume there is a right answer, but i’m going to have to defer to greater minds.

mirriam webster says —

Although nearly every handbook and many dictionaries warn against confusing principle and principal, many people still do. Principle is only a noun; principal is both adjective and noun. If you are unsure which noun you want, read the definitions in this dictionary.

yeah, that didn’t really help, but thanks!

is there a definitive answer?

i have a day job.  i wanted to participate, but not too much. i generally protect my weekends pretty tightly and don’t schedule much, so the idea of committing 54 hours to the rollercoaster that is startup mentality was a bit daunting.

i signed up anyway.

i love the strange bonds that intense shared experiences form between people – it’s one of the things that is so appealing about the startups for me.   this group intentionally or not took steps to leverage socialmedia in a perfect way to foster and extend that shared experience.

the week before the event, i was seeing updates from rob eickmann, and suggestions to start talking on pathable all generated excitement and anticipation for the event. thanks! it was really fun to enter a community where i had already met and interacted even bantered with several participants.

friday nite the pitches were inspiring! i went home to sleep trying to decide whether or not i would join a team. on saturday i almost did (sorry patrick). but, i still didn’t want to commit to a bunch of work (i was avoiding plenty back at my office). i didn’t want to risk adding one more thing to the already long list of – have to; should do; boy wouldn’t it be great if i could; omg i have to; or even boy, i want tos.

so, i meekly offered that i would do a little blogging to help nathan kaiser of npost out on seattle2.startupweekend.com. it gave me an excuse to not get involved (too much), but also poke my nose in and talk to a lot of people. my first try at live blogging an event. it was fun for about 6 hours. (sorry nathan!)

anyway there is a small point i’m making and then a great bigger one.

the small one.

i had such a great time, that i want to participate even more next year. the excitement of everyone talking about ideas and thinking about ideas and generally creating was incredibly infectious (so was the cold that i either brought to or away from the weekend).

I haven’t stopped talking about it for the last 3 days!  I’ve been watching twitter closely for #ssw2 tags.  i love that this group is local.  there are amazing resources at my fingertips and i just need to remember to get out into the community and say “hi!”

now, that leads me directly into my great big point.

everyone in this community has earned his or her geek merit badge this weekend.  through rolling brown-outs and and wifi mania everyone was geeking away– creatively connecting, moving around or throwing down old school with analog devices.  aaand, the excitement and enterprise didn’t flag.

you are amazing leaders.  i want to learn from you and revel in the infectious excitement that has fueled me this week (even as that cold catches up with me). thank you for the opportunity to join you.  i’ll be back next year chipping in anything i know but…. i still won’t stay up all night for it.  just saying.  i want to sleep.  i look forward to the next opportunity.

and, in the mean time i will – OBEY the decider.

yeah, it lacks the luster that tom music gave it when he was speaking….  guess i can’t help that.

oooh, and thanks to anthony stevens for sharing his ssw1 experience and encouraging me with a tale of geek transformation and blossoming.

before becoming a partner at blue gecko, i had a varied career as a systems and network administrator during the hey days of the dot com era at amazon.com and the ill fated ads.com. my tenure at amazon included the deployment of server infrastructure for the first satellite distribution facility in fernley nv, and the first international customer service facility in hague, netherlands. at ads.com, i was responsible for the systems and network architecture to support a concept product that warehoused information related to television advertisements and campaigns.

in a previous life, i sought a phd in physics at the university of north carolina at chapel hill.  before being lured into the world of computer science and administration i was researching nuclear scattering at tunl (triangle universities nuclear laboratory).