Enabling Happiness.

Over the course of my time working in open source communities, I’ve become pretty good at a few things:

  • Listening
  • Connecting people, ideas, stories, and other communities
  • Getting participants to believe they can do awesome things, empowering them to make them happen, and getting roadblocks out of their way
  • Listening some more

Listening is first for a reason: Without it, there are no stories to share. No people to connect. It provides me with a bit of situational awareness for both the communities in which I participate, and other communities as well. And it helps me develop a sense of empathy for what people experience, both the good and the bad, either as end users or contributors. I like to know what is working — and I like to know what isn’t working, so it can get fixed.

The truth is: I love seeing people feeling happy. Feeling accomplished. It’s one of the best things about working in open source — knowing that your work, or even the work of another community, has helped to empower people to get things done. And as a good listener, I always take note of what other projects are making people happy — and as I’ve shared elsewhere previously, one of those is Ansible.

Ansible is helping a LOT of folks feel very happy — to the tune of nearly 12,000 stars on GitHub at the moment. Some of that can be attributed to its ease of use, allowing users to quickly implement things that previously had simply been out of reach. But more poignantly, the underlying theme to the stories that I’ve heard has been that because it’s easy, because they were able to quickly accomplish things, they now had more time to focus on the hard stuff: Culture. Learning to communicate ideas and stories across multiple teams. Breaking down silos. Ansible got out of the way and enabled them to be successful beyond just the technical bits.

And it’s built by an open source community that embraces the very same principles: empowering people to contribute by making it ever easier to do so, and then getting out of their way so they can get stuff done.

I’m incredibly delighted, and a little bit honored, to share that I’m joining the team at Ansible as a Community Architect. I’ll be doing what I love to do: listening, connecting people and ideas and communities, and making sure people can get stuff done. And doing so with an terrific group of folks, including Greg DeKoenigsberg, my boss-to-be and someone to whom I give great credit for telling me I could do amazing things (and then got out of my way.)

I officially start August 3rd, but in the meantime: you can catch me at OSCON next week, largely in the hallway track, and also running the Ansible BoF Thursday night. I promise to not keep you out pasture bedtime.

Come and find me and tell me your stories.

distros and silos, devops and open source

Kris Buytaert, whom I’ve had the pleasure of meeting on several occasions at various conferences, recently wrote a blog post on the topic of systemd and devops. He is someone who has the experience of being very much hands-on with actual infrastructure in production (amongst many other talents and skills) — and insight about the various pieces that make up an organization’s infrastructure, from someone who also really understands the cultural aspects of devops, is incredibly valuable to me.

While Kris does dance around one of everybody’s favorite topics (systemd) he specifically avoids turning the post into yet another rant about systemd.  His main point: identifying that there is a gap in communication between OS developers and users. It may be lack of empathy, lack of feedback loop, etc. And Kris specifically points out that this is a starting point for discussing how to fix that gap.

Similarly, this blog post from myself is not meant to defend or justify decisions made. Nor is it to point fingers. It is to help build upon the discussion.


Having been the Fedora Project Leader up until fairly recently, I can certainly say that one of the things I worried about was this gap. If we in Fedora, and distributions in general, were becoming silos. Even though the Fedora Project is made up of contributors with skills other than development, I still worried that as a whole, we weren’t often looking outside the window to see how the rest of the world was doing work, to hear about their problems. I did a lot to try and open those windows, and share those stories, especially with the developers — because most of them have never had to manage large numbers of systems at scale. Most of them have never carried a pager that inevitably went off at the WORST POSSIBLE times. (Or dropped one down a toilet. While flushing. I did that. It was totally an accident though. Seriously.)

Bridging that gap is hard. Yes, distros could do a better job of listening to end users. This is where efforts like the OpenStack User Committee (because this issue isn’t limited to just distros) may prove to be incredibly helpful. It’s gathering and formalizing that commentary from users into something that is essentially seen as contribution to a community, in digestable form, rather than yet-another-angry-mail that represents an unknown portion of the population or community. And recognition as an actual contribution that contributes to a larger process, and ultimately success, can carry a lot of weight, particularly in communities that operate partially by meritocracy, as many distributions do.

Would something like this work in distributions? I don’t know. Perhaps it’s worth trying or floating around as an idea.

DevOps and Open Source

We talk about feedback loops a lot in the DevOps community. How to better stay in touch with and listen to and have empathy for end users or teammates. How to “build the right thing,” as the Lean Startup tells us, by showing our work as early as possible. Or, as folks in Open Source might say, “release early, release often” — because it enables transparency about what’s going on, and provides opportunity for earlier feedback and discussion.

I don’t think it’s a coincidence that DevOps and the use of open source projects seem to go hand in hand when it comes to success stories. The shared values of the DevOps and Open Source communities, when it comes to *how we practice our craft and do it best*, are often similar. Transparency. Why we document how and why things happened. Why we “release early, release often.” We all strive for continuous improvement.

You’d think it would seem natural to talk to each other. But we don’t. I think distributions are in some ways very set in their processes – and simply expect that if you want change, you’re going to show up and make it happen. And when it comes to the DevOps folks, the end users of distros and other open source projects, the focus on feedback loops tends to be with their end users — not necessarily their “suppliers.”

Where I go all Deming on y’all

I’m going to take a page from John Willis, aka @botchagalupe, for a moment, and refer you all to W. Edwards Deming and one of his 14 points for management.

“End the practice of awarding business on the basis of a price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.”

Now, if you’ve read Deming’s “Out of the Crisis,” you’ll know that this is largely related to manufacturing. Suppliers supplying you with products and parts that are screwed up or defective or not meeting your standards can SERIOUSLY screw up your day, as a manufacturer. But when you build a relationship, when there is loyalty and trust between the supplier and the user of those supplies, there is mutual understanding of roadmaps, and needs, and there is empathy and consideration.

In some ways, an open source project is the greatest supplier of all. You can see the incoming quality of code; you can see roadmaps and plans and delivery dates; you can file feature or improvement requests, and sometimes they will be implemented.

But the concept of a relationship builds upon that. (Yes, we all know relationships can be complicated, but generally the rewards are worth it, and this should be no exclusion.) Even Deming pointed out the differences between having “specifications” and knowing the whole story. And in this case: The whole story is — what are your problems? What are you trying to accomplish? What are your goals? What do you wish could be improved — whether in a distro, or in a project.

Those stories are what create empathy – and relationships. Done regularly (you know, like a loop) – those relationships can last.  Having stories, understanding the problems, understanding the practices people use on a daily basis gives developers the opportunity to not only develop empathy —  but also the opportunity to solve *the right problems*. And not go fixing things that may not actually be broken. And not feeling like the only feedback they ever get is people who are unhappy.

Generally: I think there are improvements to make all around in the closing of the gap, on both sides of the fence. But like many problems, it all boils down to empathy.

Introducing the new Fedora Project Leader, and some parting thoughts.

“I can resist everything except temptation.”  — Oscar Wilde

Recently, I announced my intentions to move onwards from the Fedora Project Leader position. Today, I’d like to share with the Fedora community, and the wider world, a few parting thoughts, and announce the name of the new FPL.

As many of you are probably aware, the FPL is employed by Red Hat, and the process of selecting an FPL is one that involves consulting with many folks both internal to Red Hat, as well as external, including consulting the Fedora Project Board. When I was approached by my former boss, Tim, as well as Jared Smith, our previous FPL, about the opportunity, there wasn’t a moment of hesitation before saying yes. It truly is an amazing opportunity to influence the Fedora Project community and the Fedora distribution, and more broadly, the pace of innovation in the larger universe of open source. I knew that the job was daunting, even all-consuming at times, and knew that many challenges would lie ahead, both for myself and the wider community.  But I also saw – and continue to see – tremendous potential, and had a million ideas already swirling in my head; while I certainly had the option to stay in my previous Program Manager role, I couldn’t possibly say no to the opportunity.

Of course, leadership doesn’t simply happen by being appointed to a position; one truly has to lead by example, by getting things done, and most importantly, by enabling and encouraging others to get things done, so that new leadership can continue to grow and flourish. One of the earliest questions I got after taking on the position was posed to me by Greg DeKoenigsberg, whom I now join in the “Former FPL Club”. And the question was this: “So. Who is the next FPL?”

While I really had no answer at the time — after discussion, it dawned on me that one of the most important parts of my job was to ensure resilience in our community; to ensure that we were nurturing new folks, so that when the day came and we were ready to move on to new things, either inside or outside of Fedora, there would be people ready and willing to step up to the task. Doing this is even discussed in The Open Source Way handbook, in the “Turn over project leaders regularly” section; the most poignant line stating, “There is no job in the world that cannot gain from a fresh mind and perspective.”


“Out of clutter, find simplicity.
From discord, find harmony.
In the middle of difficulty lies opportunity.”  — Albert Einstein

The Fedora Project is filled with opportunity; both for individuals to make a difference in a community, and for a community to make a difference in the world. Our embrace of open source principles, commitment to driving forward technology, and belief in our own Foundations keep the Fedora community engaged, enthusiastic, and perpetually moving forward.

The ability to bring people together, to unify ideas, to break down barriers, to find elegant and simple solutions to seemingly difficult problems, are just a few of the traits that a Fedora Project Leader can bring to the table to help guide the community forward. And I couldn’t be happier in announcing that Matthew Miller will be taking on the Fedora Project Leader role, as he has demonstrated over the past months and years his ability to gather the community around the Fedora.next initiatives, both from a technological and social standpoint.

Of course, Matthew is no newcomer to the Fedora Project, having been around since the *LITERAL DAWN OF FEDORA TIME* — he was an early contributor to the Fedora Legacy project, and helped to organize early FUDCons in his area of the world, at Boston University. Since joining Red Hat in 2012, he’s been responsible for the Cloud efforts in Fedora, and as the previous wrangler for that team, I was thrilled when he came on board and was willing and able to start driving forward some of the initiatives and wishlist items that team was working on. What started out small has since grown into a vision for the future, and I’m confident in Matthew’s ability to lead the Fedora Project forward into its next 10 years of innovative thinking.

And to you, lovely readers, and contributors to the Fedora Project Community: My heartfelt thanks goes out to you for your years of support, friendship, patience, and well-wishes as I move onwards; I have truly relished (ONE LAST PUN) my time as Fedora Project Leader.  I hope that you’ll all join me in congratulating Matthew on his new role, and I’m sure that his enthusiasm and fresh perspective will be of immeasurable value as Fedora moves into the future.

Thanks to you, I’m much obliged…

…for such a pleasant stay.

When one prepares to retire from the Fedora Project Leader position, there are two places in which to look for inspiration in writing their “departure advisory”:

  • Past notices of intentions to retire, such as those of my lovely predecessors Max Spevack and Paul Frields
  • Led Zeppelin lyrics

And thus, this blog post will draw a bit from both of those — but I will look to Page/Plant to kick it off:

“And to our health we drank a thousand times… it’s time to ramble on.”

(Note: A thousand times may be an inaccurate estimate.)

I’ve been in the Fedora Project Leader role for a bit over two years now, and was the program manager for Fedora for nearly a year and a half before that; needless to say, Fedora has been my full time and lots of my other time job for a long time now. Being in this role certainly is humbling and daunting at times, and amazingly gratifying at others, but it has also afforded me an almost overwhelming opportunity to learn about anything and everything going on in open source outside the Fedora universe, with the hopes of bringing those people, projects, and ideas into our folds. Some of it is incredibly interesting, and some of it brings incredibly creative thinking into solving problems that we face in the technology space today — and, like those before me, it has also led me inevitably into exploring new opportunities.

With Fedora 20 well behind us, and Fedora.next on the road ahead, it seems like a natural time to step aside and let new leadership take the reins. Frankly, I shouldn’t even say “the road ahead” since we’re well-entrenched in the process of establishing the Fedora.next features and processes, and it’s a rather busy time for us all in Fedora-land — but this is precisely why make the transition into new leadership as smooth as possible for the Fedora Project community is so important.  It’s a good time for change, and fresh ideas and leadership will be an asset to the community as we go forward, but I also want to make sure it’s not going to distract us from all the very important things we have in the works.

I’ve informed the Fedora Project Board already of my intentions, and my friends, Red Hat management and family are all aware and supportive of my decision to move onwards. Red Hat engineering and management, as the employer of the FPL, will obviously be involved in the transition process, and the Fedora Board will continue to be advised and consulted during the process as well. While what it is *exactly* that I’m doing next is still to-be-determined, I will be sticking around to help with transition tasks, general FPL-edification, and generally ensure a smooth turnover into the New World, after the proverbial torch is passed.

And “after” is a key word here, of course: Today is not my last day, or anything like that. I’m just letting everyone know of my plans to, well… Ramble On.

Stay tuned for updates.

Fedora, Red Hat, and investing in the future

It was just about 4 years ago that I hopped on a plane to go to Raleigh, North Carolina to go meet up with some folks and work on Marketing Things for an open source project that I had recently started contributing to, called Fedora.   The Fedora Marketing Team was having a FAD (Fedora Activity Day) – and I was sponsored to come out, get things done, watch some hockey, and eat some barbeque.  With the exception of my significant other, this was pretty baffling to most of my family and non-internet friends; not about what one might expect, which is, “You’re doing things for free?” – but mostly, “They’re *paying* for you to fly out there?” 

Flash-forward to the present – and while I certainly didn’t know everything that I now know today, standing in the Fedora Project Leader shoes, four years later – my answer is still remarkably similar: Red Hat invests in Fedora because it is the upstream for Red Hat Enterprise Linux. 

Red Hat’s investment in Fedora is significant; more than a dozen people support Fedora’s community infrastructure, both “people” and “technology”, in their full-time roles as Red Hat employees. Hundreds of engineers who work on open source projects upstream of Fedora integrate their work into the releases we do every 6 months.  Budget is provided for collaborative events, such as Fedora Activity Days, and FUDCons & Flocks, as well as for equipment, bandwidth, swag, event sponsorships, media, and other various services. 

Of course, being the upstream for RHEL means that Fedora is much more than simply an *integration* point. The Fedora Project community is made up of contributors from countless viewpoints and interests, both in terms of contributions and use cases. If you’ve read “The Lean Startup,” you’re familiar with the notions of “build the right thing,” and “faster feedback loops”; Fedora provides this exact model which has enabled the success of RHEL. Our rapid, 6-month cycle enables Fedora to quickly integrate the latest and greatest technology advancements – and to backtrack, tune, or adjust how those features work based on feedback in time for the next release.  This process has in turn enabled Red Hat to produce a release of RHEL every three to four years that is not only consumable by their enterprise customers, but is also expected to meet their current technological needs.

The Fedora Project recently celebrated its 10th anniversary – and its 20th release – of developing the operating system we know and love as Fedora. Over those 10 years, the technology landscape has changed dramatically, not just in terms of what and how things are produced, but also in terms of how they are consumed. It’s not particularly a chicken-and-egg situation, but more simply an evolution where technology and use have grown together. 

  1. Breadth, complexity, and velocity: We’ve seen the emergence of compute virtualization, cloud, big data, virtualization round 2 (The Network Edition), and containerization technologies, one right after the other – primarily propelled forward by technologies developed in open source communities.
  2. Agility and resilience, in both business and infrastructure: The ability to consume ever-increasing volumes of information – either about your business, or your infrastructure – and rapidly make decisions based upon that data, and *act*, is what separates successful organizations from dysfunctional ones. Increasingly, people are not building culture, or infrastructure, with permanence in mind; the need to be agile also drives the need for resilience – the ability to bounce back from failure.   More specific to infrastructure technologies, the ability to abstract, simplify, and automate enables the ability to scale in size and more rapidly develop New Stuff – which has manifested itself in a emerging sea of packaging, configuration, orchestration, and other glue-ish tools for infrastructure, many of which were born from the need to more efficiently deal with the operating system.  Organizations strive to build the right thing, the Fedora Project included, and choice abounds when it comes to technologies to enable that building.

The Fedora.next initiative is paving the way for Fedora 21 and beyond; to the most casual of onlookers, the biggest change from previous releases is the shift to building purpose-specific versions of Fedora – namely, Workstation, Server, and Cloud-image products – rather than the “one Fedora to rule them all” release that we have produced in the past.  This is, essentially, putting us far closer to “building the right thing” than we’ve ever been; it helps us to make the technologies we develop more consumable for our users and contributors, and enables a tighter feedback loop on what we are producing in a world where the pace of technology is moving at warp speed. And Fedora’s success in shifting focus to a more diverse audience via a change in product set directly enables Red Hat and other companies to have more successful projects themselves.

And speaking with my red fedora on – Red Hat, of course, does hope to benefit from these new purpose-specific products and the emerging work around them. Just as a single-purpose Fedora has helped select technology for today’s RHEL, Red Hat hopes this diversity will do the same for future RHEL. The communities that are springing up around Linux and open source development have become very diverse, and so have Red Hat’s customers, and product lineup. The more appeal we generate with Fedora for those communities and use cases, the more value Fedora adds to the cycle of participation and integration. Since Red Hat’s engineers end up working on many parts of that cycle through free and open source upstreams and integrating in Fedora, it’s no surprise they’re interested in helping Fedora get these new products well thought out via the working groups. Bettering Fedora’s appeal also directly impacts Red Hat’s ability to build its ecosystem and thereby bring even more participation to, and investment in, Fedora.

All that said – our own need in the Fedora community to build resilience and agility, in both our infrastructure and culture/community – are key to successfully launching three products. The process isn’t going to be as easy as flipping a lightswitch (sorry, folks!), but rather more of an evolution. Many new things are already underway in terms of new technology – such as our work on coprs, collaboration with Docker, or the (IMO) exciting work going on in the Cloud SIG around atomic upgrades  – as well as rethinking some of our existing processes around how we build and test our products. As we navigate through this process, our fearless program manager, Jaroslav, will be helping to coordinate and plan how all of these pieces fit together – and I encourage you to keep an eye on those planning details and dependencies so that we can deliver a Fedora that is prepared for the next 10 years of technological innovation.

I’m a fan of the concepts behind the new purpose-driven products, and I encourage you to bring constructive inputs to the mix. Of course, I’m also delighted for people to bring contributions around the products —  just as we’ve done for our past 20 releases. It’s an exciting time for Fedora, and a great time to be involved and to influence the next 20 releases to come. (Or more!)


It’s been hard to get words down on paper, so to speak. I got through a day without – well, not without crying or being upset, but at least without spontaneously combusting in a flood of tears. Which made it feel like it was okay to try to write about it all now.

The last time I talked to Seth on the telephone was July 1st. At least, that’s what my cell phone tells me, along with a duration of 143 minutes. It wasn’t an uncommon length of time for us to be on the phone; in fact, it was almost a regular weekly occurrence to have a call that long, sometimes with shorter calls in-between.

Of course, it didn’t start out like that; we first started talking somewhat regularly last year, while he was undertaking the project of building magical cloud infrastructure for Fedora. I had plenty of breadth of knowledge in that space, and he wanted to get some perspective; I still remember feeling a bit like, “I must appear as though I know more than I actually do,” because here was Seth, this utterly brilliant guy, calling *me*, the Jack of all Trades, Master of None – for a consultation on various technical solutions and thoughts on the health of various communities and projects.

Those first one-on-one conversations contain hilarious memories; instances of us discussing something, followed by him dropping a choice four-letter word, and then pausing:

Seth: “Oh, god, I’m sorry, did I just offend you? I really didn’t mean to if I did. It just sort of happens.”

Me: “I’m pretty sure that it’s not actually possible to offend me. I’m also pretty sure I’ve already used that word about 6 times in the past 10 minutes.”

And so it repeated in following conversations; eventually, I must have convinced him that I really wasn’t bleaching out my ears after our phone calls.  He didn’t ask anymore, but then again, we discovered there was plenty of other discussion to be had.

There was something — well, many things — lovely about talking to Seth, at least for me. We’re both fairly… well.. highly cynical; I never had to double-check to make sure that he understood that I said something in sarcasm; and yes, it’s nice to talk like a sailor without worry of judgement. That makes for nice, common ground — talk freely as the person that you are.  I could call him with hair-brained idea #482, and he wouldn’t just listen and say, “Mmhmm,”; he would listen to what I was trying to say, ask lots of questions, and translate what I was actually trying to express into appropriate technical terms, and make sure that I understood the ins and outs of those technical things, before we even debated about the merits and woes of said hair-brained idea. He was patient, and kind, and actually gave a shit, and that is a pretty rare thing.

Seth, of course, had plenty of his own things to discuss that he was excited about.  Just a little over a month ago, while I was at Red Hat Summit, someone mentioned to me that Seth was *here* and needed a booth-only pass of sorts, and, oh, that was the coolest thing I had heard ALL DAY. I knew he wasn’t in the house for Summit, but rather, for AnsibleFest – Ansible being a project that he had become particularly fond of – and I had remembered thinking that he reallyreally should go, and I was just tickled pink that he actually was able to make it to an event around something he was excited about.

Selfishly, I was also just delighted to see him, and to have a moment to talk about All The Things in person. As I prepared to go figure out getting him a booth pass, I idly wondered to myself about what I should put on his nametag – and snickered a bit thinking about having it say “Creator of yum” – we had recently had a conversation about how often it was that someone would find out who he was, and that he had made that thing, and proceed to relentlessly ask him about why it didn’t do X, Y, or Z, and did he ever think about various conundrums, etc. And then proceeded to explain his perception of how some people would treat him:

<skvidal> the general attitude that yum has never worked or been functional and that everyone who has ever worked on it is clearly a mouth breathing cousin-brother named cletus

I’m pretty sure I had to apologize for suddenly disappearing from the keyboard — no no, I’m not bored or distracted, I just had tears of laughter rolling down my face to the point that I couldn’t type or function or do anything but laugh. A mouth breathing cousin-brother. OMG. I laughed, and laughed, despite it not actually being funny at all; I knew it was tiring, something that eats away at your soul a little bit, I knew the feeling.

I wound up putting his actual job title on his badge; he was able to pick it up, and eventually we chatted in a hallway for a bit. We agreed to try and meet up later that night, as Eunice had come up to Boston with him. We had been on the phone just a week or two earlier, and Seth had reported that Eunice was totally excited to meet me, because he had told her that there was another female that cursed a lot!, and both he and she thought we would get along just fabulously, and he relayed my more-profane version of “Hell yes!” back to her, and we all had a good laugh, and were looking forward to meeting at Flock. But now an opportunity presented itself even sooner than Flock, and so we made incredibly loose plans for the evening.

As it happened, he talked so much at AnsibleFest with others that his voice gave out; he texted me and let me know, and I had gotten wrapped up in other things, and it was all going to be fine anyway, because Flock was right around the corner. Sadly, instead I met Eunice at Seth’s service, a rather bittersweet meeting under circumstances none of us ever envisioned.

I know it sounds cliche to say, “It was a lovely service,” but it really was; it was meant to be a celebration of his life, and certainly lived up to that. It’s funny how you can think you know someone *so well* – and find out that there was so, so much more. Seth was just as much an institution of sorts in more than just Fedora; it was also the cycling community, the local foodie community, his neighborhood.  Stories from former co-workers, classmates, friends in every area of his life that he was passionate about, about the times they shared, the times he helped them out, the time he always took to listen, intently, as friends do.

And the photos. So many. Not just the photos from his youth, which we all peered at, getting the sense of him as he was growing up, and being able to recognize the time periods – ah, this was the 80’s, this is definitely the 90’s, perhaps this is high school or college years for him. Streaming on the projector were more recent photos; Eunice enjoys photography a LOT, and the screen clicked slowly through photos of him, time-delayed photos of them together, bicycling, eating, cooking, enjoying life.

One photo in particular was noticeable enough for me to remember; a picture of Seth, taken from above, his head resting face-up in her lap. And you could see the look of  happiness on his face; a bit of twinkle in his eye, a broad smile on his face, but not of an ordinary, “Smile for the camera!” type of look. He’s not looking at the camera, he’s looking at the photographer — with a look that is the unmistakable look of absolute, joyful love. The kind of love that everyone should be so lucky as to have.

Seth never half-assed anything. He put 200% of himself into the things he cared about, and the people he cared about, which is why he was such an integral fixture in all of the communities in which he participated, and he cared about doing those things right, and fairly, and really, with love.

I talked to Seth a bit on IRC on that Crappy Monday; I was on vacation, but had a few things I wanted to pick his brain on, and he wanted to hear them, and we planned to talk Tuesday morning. I think about all of the phone calls we did have; the number of times where we were just about done talking, and needed to go to dinner, or to tend to other things going on, but he’d say something like, “Oh, one other thing,” in that pointed manner in which he spoke, or – as so many others have mentioned – would ask me, “How *are* you doing, by the way? Are things okay? Are you good?” – and it would be another  5 minutes before the things on hold were actually now delayed, and we’d *really* hang up. Why didn’t I just pick up the phone and call him anyway? Would that have been the 5 minutes that delayed the entire course of his day, that day? Because that phone call, tomorrow, didn’t happen, of course.  Oddly, even though I know he’s no longer with us, I still find myself chewing over things and suddenly having the thought of wanting to call him, because I REALLY want to share something, and then after that miniscule moment of  – I don’t know if it’s forgetfulness or just simply being wishful – I realize, I can’t. Ever.

What *was* the last call — those 143 minutes, where I remember distinctly hanging up and thinking to myself, “Wow, that was a short call for Seth and me,” and then looked at the clock and said, “Oh, that wasn’t short at ALL,” and chuckled to myself about how easily the time passes — oddly, I remember that part distinctly, but the rest of the conversation, not so much. I do remember the very, very last part of the conversation though, just before we hung up; I can’t remember how we got there, but basically, we were debating the ways to lay down the law, and the different attitudes one can take in doing so, and we spent an eternity trying to remember the name of a long-since-heard-from person who was particularly abrasive. After googling for that person’s, well, particular function at that long-since-past point in time, in combination with the word “asshole,” we breathed a sigh of relief at knowing the name, that it wasn’t going to irritate us individually all night long, laughed that it was the first match on google. And then Seth said:

“You know, sometimes I think the world needs more assholes.”

I forget what I said; I’m pretty sure it was something to the effect of the world having enough assholes already.

What I would say now is: The world needs more Seth Vidals.  People who live life to its fullest, people who *actually really care*  about causes, and individuals, and take the time to listen, and to do, and to act. And while I can wish with all my might to just simply have one, just one Seth Vidal, THE one Seth, back in all of our lives, it won’t happen; what I do know is that, whether it’s my forgetfulness or wishful thinking, I’ll still have those times that I’ll want to call him, and I  know that I can still use those moments to think about what he’d likely say.

Miss you, Seth, and I’ll talk to you tomorrow, even if only in my head.

Remembering Seth.

In the days since his passing, many people in the Fedora Project community have asked how they can pay tribute to Seth. Details follow below.

Finally, numerous suggestions and wishes have been made within the Fedora community to honor Seth. The Fedora Board has agreed that the Fedora 20 release will be dedicated to Seth.  Additionally, a number of options are being explored for the upcoming Flock event; these will continue to unfold over the next month.