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!)

Welcoming the CentOS Community to the Red Hat family.

Welcome, CentOS community folks, to the wider family of Red Hat sponsored community projects.

Just a short bit ago, Red Hat and the CentOS Project jointly announced the creation of a formal, collaborative relationship, which effectively (for lack of a better metaphor) “adopts” the CentOS project into the family of other Red Hat-sponsored communities such as the Gluster Community, OpenShift Origin, the JBoss Community, and of course, the Fedora Project.

From the perspective of Daddy Shadowman, this is Big News, of course; from a community perspective, frankly, it’s something that I think should have been done long ago.  I know that many people, myself included, have friends contributing in one way or another to CentOS, or contribute themselves, and have long considered CentOS to be part of our ecosystem; having the “blessing,” and support, of Red Hat, is something I see as a Good Thing. More about those Good Things shortly. In the meantime:

If you haven’t read the FAQ, I encourage you to do so. I know that lots of folks generally assume that an FAQ is not going to have a lot of information, but in this case it is actually quite replete (in fact, I have joked that when printed, it weighs approximately 6 pounds), and will likely answer any questions that people might have. For those interested, there is also a webcast with Brian Stevens, our lovely CTO, at 5pm Eastern; and of course you can head on over to the CentOS Project website to get more information. (Or to get acquainted, if you aren’t. But seriously; I know you are. Come on.)

Despite the plethora of available information, I expect that there may be folks within the Fedora Project community who will have questions above and beyond the answers provided in the FAQ. The Fedora Project just recently celebrated its anniversary of 10 years as a community; both Fedora and Red Hat have grown tremendously during those 10 years, and the Fedora Project’s evolution as a community, and what Red Hat has learned during that process, has paved the way for many of Red Hat’s other communities’ successes. But more pertinently: the Fedora Project is a community that deeply cares not just about ourselves, but also about other communities, and about the state of free and open source software in general. And thus, I know some questions that may arise may come not only from our own experiences as a “Red Hat sponsored community project”, but also out of our deep knowledge of “how the sausage is made,” so to speak, and curiosities may be sparked about various technical implementation details. I’m happy to answer those questions where I can, either personally, or on the Fedora Board list; other questions might be more appropriate for other groups, such as the Infrastructure team, or even on the CentOS mailing lists themselves. I trust that most folks within the Fedora Project can figure out where to direct such questions.

That said – I’m happy to provide a bit more Fedora-related context, in the hopes that it might appease curiosities, and also because I would hate to see a perfectly good roll of tin foil go to waste on an unnecessary hat. :) And so, a few points follow:

  1. The new relationship between Red Hat and the CentOS Project changes absolutely nothing about how the Fedora Project will work, or affect the role that Fedora fulfills in Red Hat’s production of Red Hat Enterprise Linux. Fedora will continue to set the standard for developing and incorporating the newest technological innovations in the operating system; those innovations will continue to make their way downstream, both into Red Hat Enterprise Linux, CentOS, and many other -EL derivatives.
  2. Those of you who are Fedora Package Maintainers are not now suddenly obligated to maintaining anything in the CentOS Community.  Additionally, this does not affect Fedora’s EPEL work; this will continue to be something that the Fedora Project provides, as long as it wishes to do so.
  3. The Fedora and CentOS communities are not going to be “forced” somehow to work together.  Obviously, there exists a number of places where we have overlap in processes, build infrastructure software, and the like, and we certainly have the opportunity ahead of us to cooperate and share when it makes sense. The CentOS folks will be having a more transparent build system, and building out a release and infrastructure community – areas where we have expertise in what is incredibly similar tooling; similarly, they also have deep pockets of expertise in various types of automated build testing that haven’t become a critical part of Fedora’s culture yet. As I said previously – there are already numerous friendships forged between members of these two communities, and I would expect that over time, the things that make sense to collaborate on will become more obvious, and that teams from the two respective communities will gravitate towards one another when it makes sense.

In short: Nothing is really changing for those of us in the Fedora Project, at least in any way that we don’t choose to change ourselves. But 10 years of our own evolution as a project certainly doesn’t mean that we’re done growing, learning, changing over the next 10 years, and beyond. As the CentOS Project continues to nurture and grow its own community, I expect that many of those community members will naturally more interested in understanding how to influence the future of RHEL – the thing that eventually becomes CentOS – which is, of course, the space where we in the Fedora Project shine. While this was possible before, the “blessing” by Red Hat allows the CentOS project latitude that didn’t really exist before as far as “reaching out.” The great opportunity for Fedora now is not only to help those community members make that trip over the bridge from the downstream community to our upstream community, but also to tap into the wealth of end-user expertise and hands-on experience that is had by the collective community of CentOS users – and seriously, THERE ARE A LOT OF THEM – and to really listen, to create a feedback loop from those ultimate end-users back to the developers who are creating what will become the next generation of Red Hat Enterprise Linux. And make it even better.

(Those are those Good Things to which I previously referred, BTW.)

I hope that everyone in the Fedora Project can join me in welcoming CentOS to the Big Happy Family.  I talked to Karanbir Singh, my counterpart in the CentOS project, on the phone yesterday, and expressed this, but it’s something I mean from the bottom of my heart, and isn’t just for him, or my other new coworkers (Jim Perrin, Johnny Hughes, Fabian Arrotin – welcome, guys!) — but really, for all of the extended CentOS Community: I really hope that this goes smoothly for you guys. And if you have questions, about anything – I’m here, and I’m sure many others in the Fedora Project will be here too. We’ve been down many of the paths that you guys will see in the future – and hope that you guys can benefit from our past experiences. So don’t hesitate to ask. Really.

Congratulations to all of you.

List o’Books

At Flock I had a slide with a list of books I’ve read recently (or, in some cases, re-read recently).

Image

A few folks have asked if I could post said list, with author information and such, and here it is, replete with some of the other books I’ve forgotten about, and even bucketed by categories of sorts.

My top books from this list: OH GOD, where to start. I’d say: The Strategist, Multipliers, The Story of Purpose, Resilience, Phoenix Project, Lean Startup, not necessarily in that order.

Agility/Resiliency/Devops-y things:

  • The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Gene Kim, Kevin Behr, George Spafford): It really is a novel. And you probably identify with at least one person in it. It’s the story of the transformation of an IT organization to devops-ways of thinking; going from a team riddled with technical debt and more work than can ever be accomplished, especially with non-stop emergencies — to breaking down silos, eliminating single points of failure, saving the company through their brilliance. A great read that introduces you to kanban, agile, devops concepts, and shows you, most importantly, that devops is not just tools. Also, in person, Gene is just a super nice guy, a fun speaker, full of energy and insight.
  • Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation: (Jez Humble, David Farley): If you have interests in testing automation, continuous integration, config management, quality, or other related things — this is the book to read. You can see a video of Jez Humble talking about continuous delivery at Puppetconf last year if you’d like a high-level overview to get you hooked enough to read – doing the topic justice by covering everything from “Build the right thing” to Deming to actual real-world implementation tips.
  • The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (Eric Ries): Speaking of “build the right thing” — if you’ve heard people talking about feedback loops or pivoting, they probably read The Lean Startup. It’s all about deploying implementations of ideas faster, in smaller pieces, so you can take feedback loops to build things people actually want – rather than getting to the end and discovering nobody cares. (Hmm. Sounds a bit like “release early, release often,” doesn’t it?)
  • Lean Analytics: Use Data to Build a Better Startup Faster (Alasdair Kroll, Benjamin Yoskovitz): Building upon the ideas in the Lean Startup — this book looks to actual hard data to help make decisions. Covers a lot of nitty gritty around statistics, page views, that kind of jazz, which was a little more than I wanted to know, but the parts I read were useful enough to make me feel like I got value despite some of the parts I skimmed.
  • Resilience: Why Things Bounce Back (Andrew Zolli): This book is very much organized around organizational resiliency – rather than “infrastructure resiliency,” for example – and I highly recommend it, particularly for people involved in open source communities.

Strategy and Endearment for organizations:

Leadership-ish things:

  • Multipliers: How the Best Leaders Make Everyone Smarter (Liz Wiseman): One of those books where you think a bit that you sort of inherently knew (or already do!) some of the things in here, but really opens the doors on how meaningful those things can be in inspiring and influencing others. It’s all about planting seeds, nudging people to chase their questions and ideas and imaginative thought processes, among other things.
  • Leadership Rules: 50 Timeless Lessons for Leaders (Jo Owen): More on the obvious advice side, less on the illumination side, of leadership.

Filed Under “Other”, and Things Always Worthwhile Re-reading:

  • The Wisdom of Psychopaths: What Saints, Spies, and Serial Killers Can Teach Us About Success (Kevin Dutton): Picked this up a while after reading an article in Scientific American by the same author on the topic of psychopaths, and how their abilities to charm, be confident, etc. aren’t simply useful in the more-commonly known depictions of psychopaths (ie: serial killers, etc.) – but also useful for getting ahead in the business world. (I’m also just an armchair psychiatrist and find the whole spectrum of personality disorders interesting, particularly the intersections of antisocial personality disorder with sociopathy and psychopathy; I’d add the DSM to this list, but I haven’t picked up DSM-V yet, I only have DSM-IV on my shelf.)
  • The Art of War (Sun Tzu): To be clear: This is the “Art of War” by Sun Tzu, not the “Art of War” by Niccolo Machiavelli. There are numerous translations available, and being a timeless book there typically are numerous translations also available at larger bookstores; I recommend taking a jaunt to your local shop and looking through a few of them to see what they have. I recommend getting one that has not just “the interpreted translation” but also one that has some context in-line (“what he means here is”) if you’re a first-time reader. I have a few copies of this book, including one that is an all-in-one-volume combined with “On War” by Carl von Clausewitz.
    • (If you’re going down the Machiavelli path, I recommend reading “The Prince,” his most well-known work.)
  • The Innovator’s Dilemma (Clayton M. Christensen): Just read it. Seriously.
  • The Starfish and the Spider: The Unstoppable Power of Leaderless Organizations (Ori Brafman, Rod Beckstrom): Catalysts. Community. How to bring people in. Go read.

Seth.

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.

Board Meeting Topic for the day: User Base, aka target audience

In case you missed the mail, there is a Fedora Board IRC meeting today, at 17:00 UTC, in #fedora-meeting-1 on freenode. AKA: IMMINENTLY. Anyone is welcome to join, and so I hope you’ll come.

Today’s topic is Fedora’s defined User Base, also commonly referred to as target audience, and whether or not that continues to be an accurate definition; and thus, by extension, if the Default Offering continues to be correct, if the messaging we put out continues to reach the correct audience, and if decisions made about how Fedora is made/what it is composed of/how it is positioned *as it is delivered* match up with the user base.

A few handy bits of information for you:

  • What is the Fedora Project?: This page provides highlights of a handful of interesting items, including: Vision Statement, Mission, Objectives, User Base, Core Values, etc.
  • User Base (aka target audience): Detail about “a set of four characteristics that describe the minimum level of consumer for whom we’ll design the default offering.” These characteristics include: Voluntary linux consumer; Computer-friendly; Likely collaborator; General productivity user.
  • Default Offering: This page describes the pieces of technology that we should deliver to meet the needs of the User Base, and how we would deliver them (aka: media formats, etc). In other words: If someone clicks to download Fedora, this should be the most likely thing that they are going to use.

WHY LOOK AT THE USER BASE?

So, I’ll be honest: I’ve written this blog post a few times. It winds up being really, really, really, really long. So I’m going to break it up into a few posts over the coming days (YAY SUSPENSE), but in the interim, I’ll say this:

I’ve done strategic-thinking things as my job in past $dayjobs. While you want to have a mission and vision that is more long-lasting, as a technology company or project, you have to recognize that the *roadmap* to how you deliver on that mission and vision is subject to being affected by many trends, market forces, and the like. The mission may be the same, but how it’s achieved needs to be examined from time to time (I would argue almost on a yearly basis) to ensure that the assumptions you’ve made continue to be true, that you are reacting properly to market influences, user trends, etc. 

I would argue that a LOT has changed in the years since our user base was defined. I believe that many of the decisions we make, the messaging we provide, come from our definition of the user base. And I’m not sure that it continues to be *the best* definition at this point. Moreover, I’m not sure that what we are actually delivering matches up with that user base.  Deliveries come from contributors who are willing to do the work, not from wishing. :D

Anyway. More to come! Join us for the meeting today. I’m sure it will be, um, interesting. :)

Car parts vs. a Shiny Blue Car: What makes a better Fedora story?

For a very long time, when putting together release announcements, talking points, or other marketing-related materials, we’ve tended to group features (or, in the future, “changes” as approved by FESCo, + “shiny” as approved by presumably marketing or docs) into the following 3 categories: Users, Developers, and Sysadmins. (And of late, Cloud, or virt & cloud.)

Which has seemed reasonably fine, and may well still be fine, or at least, not broken. The question is: Are these groupings adequately representing the coolest things Fedora has to offer?

My line of thought, comments are welcome:

  1. The lines are increasingly blurry between these three areas. Seriously blurry. Particularly on the dev/sysadmin end of things (who is packaging more for? What about a PaaS? Is syslinux, an optional bootloader, more for a user or a sysadmin, if I’m just using it to boot my own guests and i’m not necessarily doing the role of a sysadmin?).
  2. We write a LOT of stuff that basically sounds like this (and I will use references from the current feature list to illustrate, along with language I wouldn’t actually use in a release announcement, if you are worried):
    • We have things for sysadmins. They include:
      • Checkpoint/restore: Enables checkpointing for processes
      • High availability container resources: Use the cluster stack to manage VMs and discover/use containers on those VMs
      • systemd resource control: dynamically modify c-groups based resource controls for services at runtime
      • syslinux: optional bootloader, ideal for cloudy things, virt appliances
      • Thermostat: tool for monitoring/servicing java apps as they run
      • etc.
    • Other things for users
    • Even more things for developers

…Which basically sounds, IMO, like we have a bunch of stuff, mostly with vaguely technical descriptions, and not very often a description of *what that actually means* to the potential end user / audience, nothing out there to grab the eye of someone who is wondering what is in Fedora that will solve specific problems or use cases they have.

So: As described in mail to Docs and Marketing – I’m wondering if it makes more sense to tell the *stories* or overarching themes that we seem to have in a release – which could well change from release to release – if that helps show that there are improvements in broader areas, helps to define use beyond “the how to” into the “what for” area.

As a suggestion/draft, I wrote up the following areas & short (unrefined) descriptions to the docs and marketing lists, and am adding in some possible examples of what could go into those stories HERE, on this lovely blog post. These are basically the three big areas I see of “cool stuff” going on, primarily around “things that are NEW” and not incremental improvements (but not totally detailed, just a quick draft of potential feature matchups):

What do you think? It seems like “manage” often has overlap with start and recover.  I think there would be a need to extend the bucket descriptions as to “why it’s important” – ie, “start and recover is often a focus point for those running applications in the cloud,” etc.

You’re welcome to come be part of the development for the F19 talking points (or at the bare minimum, the process in which we contemplate which features are best for highlighting).

If your feature doesn’t yet have a reason by it, don’t panic: It may be that your feature is less “totally new” and more of an incremental change, which may not land it on the Talking Points page (but may well stlil land it in others mailboxes. OR… it could be that, at first glance, it was hard to determine *what this actually means* to the audience by just looking at the feature page. Seriously: If you have a feature in F19, and you can tell some overriding story about what it means *in practice* – let me know here (on blog), or join up to the marketing list, or join us in #fedora-mktg.