Monday, June 01, 2020

Podcast: Was open source inevitable? (Part 4)

EPISODE 4: HOW OPEN SOURCE WON—OR DID IT?

In this four-part miniseries within the Innovate @Open podcast, we explore the alternative histories of open source software through the voices of many of the people who lived through its rise.

In this fourth and final episode, we consider our last counterfactual: Was open source mainstream commercialization inevitable and what role did the IBM turn-of-the-century investment in Linux make to the ultimate trajectory of Linux and open source? Was that investment even a sure thing? We then wrap up the series by thinking about where open source is today. Has it really won? What are the challenges ahead? What should we be cautious about taking for granted?

On this episode, we're joined by the following guests:
  • Irving Wladawsky-Berger, formerly led IBM internet then Linux strategy
  • Chris Aniszczyk, Linux Foundation
  • Matt Asay, AWS
  • Dave Neary, Red Hat
  • Steven Vaughn-Nichols, CBS Interactive
  • Diane Mueller, Red Hat
  • Bryan Cantrill, Oxide Computer
  • Mike Bursell, Red Hat
  • Rob Hirschfeld, RackN
Related links:

Tuesday, May 26, 2020

Podcast: Was open source inevitable? (Part 3)

EPISODE 3: OPERATING SYSTEMS FOR A HORIZONTAL STACK

In this four-part miniseries within the Innovate @Open podcast, we explore the alternative histories of open source software through the voices of many of the people who lived through its rise.

In this third and penultimate episode, we play out the great Linux vs. Windows rivalry of the 1990s and 2000s. What might have happened had Linux Torvalds decided to take up ice sculpture instead of writing Linux? Or what could a kinder, gentler, and more politic Microsoft have done to steer history further in its favor to the detriment of the Unix and Unix-like operating systems?

On this episode, we're joined by the following guests:
  • Steven Vaughn-Nichols, CBS Interactive
  • Bryan Cantrill, Oxide Computer
  • Brian Proffitt, Red Hat
  • Rob Hirschfeld, RackN
Related links:

Monday, May 18, 2020

Podcast: Was open source inevitable (Part 2)

EPISODE 2: THE FOUNDATIONS OF A MOVEMENT

In this four-part miniseries within the Innovate @Open podcast, we explore the alternative histories of open source software through the voices of many of the people who lived through its rise. The central question is “Was open source inevitable?” Not necessarily in the particulars but in the macro.

In this second episode, we consider whether some of the foundational elements of modern open source were inevitable. Unix is intertwined with the history of open source, including but not limited to Linux. Did something like it have to come about? And what about Richard Stallman and the Free Software Foundation? Would things have played out differently absent this political dimension of free software? Finally, what of the role of copyright law and licenses more broadly.

On this episode, we're joined by the following guests:
  • William Henry, Red Hat
  • Mike Bursell, Red Hat
  • Dave Neary, Red Hat
  • Richard Fontana, Red Hat
  • Luis Villa, Tidelift
Related links:
Note: This podcast references the University of Washington license for Sendmail. Sendmail uses the Sendmail license written at the University of Washington.

Listen to the podcast (MP3 - 31:40)

Monday, May 11, 2020

Podcast: Was open source inevitable? (Part 1)

EPISODE 1: SETTING THE STAGE

In this four-part miniseries within the Innovate @Open podcast, we explore the alternative histories of open source software through the voices of many of the people who lived through its rise. The central question is “Was open source inevitable?” Not necessarily in the particulars but in the macro.

In this first episode, we consider those factors that probably were inevitable in more or less the form that we find them today. We then take the listener through the history of open source software by way of background for the upcoming episodes.

On this episode, we're joined by the following guests:
  • Andy Grove, former CEO of Intel, by way of a clip from a 1996 talk at MIT
  • Irving Wladawsky-Berger, who ran internet and then Linux strategy at IBM
  • Chris Aniszczyk, Linux Foundation
  • Harish Pillay, Red Hat
  • Jan Wildeboer, Red Hat
Related links:



Thursday, April 02, 2020

Podcast: If Linux didn't exist, would we have had to invent it?

I've been working on a multi-part podcast series that considers the question "Was open source inevitable?" through interviews with many industry experts. The series will be produced/edited as opposed to just straight-through interviews. However, in the course of talking with people and doing research, I got into a bit of a debate with Bryan Cantrill and Steven Vaughan-Nichols on Twitter.

I've known both of them for ages. Bryan Cantrill is a co-founder of Oxide Computer and a longtime employee of Sun Microsystems where he was, among other things, responsible for creating Dtrace in Solaris. Steven J. Vaughan-Nichols, aka sjvn, has been writing about technology and the business of technology since CP/M-80 was the cutting edge and is a contributing editor at CBS Interactive. They agreed to hop on a call together and debate the question posed in the title. Consider this a teaser for the upcoming series.

Bryan's take is that the general arc of open source operating systems was more or less inevitable. Steven's not so sure and sees Linux as a very important ingredient in the software mix associated with the early days of the commercial Internet—without which things would have played out differently.

I mostly stayed out of their way. Listen to their spirited debate about Linux, Perl, the LAMP stack, and more.

Listen to the podcast [MP3 - 36:30]

Tuesday, March 17, 2020

A new project: Was open source inevitable?

Last fall, I listened to the episode Was the Protestant Reformation Inevitable? on the Tides of History podcast. It turns out to be a fascinating question both because of the importance of the event and the difficulty of giving a definitive answer. I encourage a listen.

However, for me, it turned out to be fascinating for another reason as well. It got me thinking that a similar question could be asked about open source. And this got me excited because I'm a big believer in how history and counterfactuals can shed a lot of light on current and future processes—such as those around how open source software (and other types of openness) might develop in the future.

My plan is to turn this into a miniseries within my existing Innovate @Open podcast. Although my podcasts are normally fairly straightforward one-on-one interviews, this three(?) parter will be more produced and feature edited interviews from a variety of guests interspersed with commentary and perhaps historical material.

I had originally planned to do most of the interviews at events and I had started to do so. But with essentially all travel shutdown at the moment I'm taking advantage of the relative lull to reach out to people.

If you think you have something to add, feel free to get in touch. I'm mostly interested in ways things could have played out in a materially different way. Perhaps not without open source at all but a materially different landscape.

Monday, March 16, 2020

Podcast: Hyperledger's Arnaud Le Hors on best practices for Technical Steering Committees

Arnaud Le Hors is the chair of the Hyperledger Project's technical steering committee (TSC). Earlier this month, I sat down with Arnaud at the Hyperledger Global Forum to talk about the role of technical steering committees and some of the things that they've learned with Hyperledger over the past few years.

The Hyperledger Project is a group of related enterprise blockchain projects under the umbrella of the Linux Foundation. However, in this discussion, we didn't focus so much on the technology but, rather, on how best to manage a project from a technical perspective. Perhaps the most interesting part of this discussion related to how managing a project like this one is at least as much about process as it is about the core technology. Example. What could the TSC have done better? Document everything!

Some related links:
Hyperledger Project
Hyperledger TSC Home
Open governance insights from Chris Aniszczyk, VP of Developer Relations at the Linux Foundation
Blockchain reality check 2020: Challenges and winning applications (write-up from Hyperledger Global Forum 2020)

Listen to podcast [MP3 - 24:11]

Saturday, March 14, 2020

Favorite Science Fiction Short Stories: First Draft


I've been playing around with re-reading favorite science fiction short stories and seeing if there's anything that has managed to elude me over the years. (Or at least I've totally forgotten if I did read it.) It's not always as easy as it seems as if it should be to track down individual short stories--at least legally. But that's a story for another day.

Anyway, my initial list (sorted chronologically) is below. A few rules I set for myself:
  • One story per author. Certainly there are many on this list for which I could effortlessly reel off multiple deserving entries.
  • I didn't worry about exact definitions. There are stories here that are longer than the science fiction awards definition of a short story.
  • I didn't cut a lot of slack for popular older stories that require a lot of historical perspective to appreciate today.
  • I also didn't include authors who I like for their novels but don't have any short stories I'm aware of that really wowed me. 
  • I tried to pick stories that work well in isolation. For example, while I really like Larry Niven's Known Space stories, I think "Inconstant Moon" is probably his best standalone story.
Who am I missing? Are there any of my picks that you think are really off?

The Machine StopsE. M. Forster1909

A Martian OdysseyStanley G. Weinbaum1934

Microcosmic GodTheodore Sturgeon1941

The Weapon ShopA. E. van Vogt1942

Mimsy were the BorgovesLewis Padgett (pseudonym)1943

A Logic Named JoeMurray Leinster1946

The LotteryShirley Jackson1948

Scanners Live in VainCordwainer Smith1950

There Will Come Soft RainsRay Bradbury1950

Surface TensionJames Blish1952

It's a Good LifeJerome Bixby1953

Fondly FahrenheitAlfred Bester 1954
The StarArthur C. Clarke1955
The Last QuestionIsaac Asimov1956
All You ZombiesRobert Heinlein1959

Flowers for Algernon (short story)Daniel Keyes1959

A Rose for EcclesiastesRoger Zelazny1963
Repent, Harlequin!' Said the TicktockmanHarlan Ellison1965
Light of Other DaysBob Shaw1966
We Can Remember it for you WholesalePhilip K. Dick1966

Aye, and GomorrahSamuel Delany1967

Inconstant MoonLarry Niven1973

Ender's Game (short story)Orson Scott Card1977
SandkingsGeorge R. R. Martin1979
The Gernsback ContinuumWilliam Gibson1981
True NamesVernor Vinge1981
Buffalo Gals, Won't You Come Out TonightUrsula Le Guin1987

Bears Discover FireTerry Bisson1990

Even the QueenConnie Willis1992
Story of your LifeTed Chiang1998

Wednesday, March 11, 2020

Podcast: Open hardware and firmware with Bryan Knouse of Project OWL

Project OWL (Organization, Whereabouts, and Logistics) has developed a mesh network of Internet of Things (IoT) devices called “DuckLinks” that can be deployed or activated in disaster areas to quickly reestablish connectivity and improve communication between first responders and civilians in need. On March 10, the Linux Foundation announced that Project OWL’s IoT device firmware effort will be hosted at the Foundation.

In 2018, Project OWL was the global winner in the inaugural Call for Code Global Challenge, competing with more than 100,000 participants from 156 nations. The Call for Code Global Challenge encourages and fosters the creation of practical applications built on open source software, with a focus on immediate and lasting humanitarian impact in communities around the world. “Project OWL was our first Call for Code winner that went through the Code and Response incubation process, and we’re excited to see this solution grow closer to reality,” said Daniel Krook, IBM Chief Technology Officer for Call for Code and Code and Response.

Listen to the podcast [MP3 - 16:15]

Tuesday, February 18, 2020

Podcast: Nextcloud founder Frank Karlitschek on breaking away from the cloud

Frank founded the ownCloud project in 2010 to put home users and enterprises back in control of their data. To bring file sync and share technology to the next level and better align to the needs of users and customers he founded Nextcloud in 2016. We caught up at FOSDEM in Brussels earlier this year to talk open source.

Among the topics we covered were:

  • Nextcloud
  • How users/organizations have become more sophisticated about hybrid cloud and multi-cloud and have generally rejected making a binary choice
  • Reasons why some of his customers have chosen to self-host storage and collaboration
  • Why we should talk more about the freedoms that come from choosing open source

Listen to the podcast [MP3 - 11:50]

Monday, February 17, 2020

Podcast: Red Hat's Harish Pillay on open source and sustainability

One can look at sustainability through a number of different but related lenses. What incentives (and education) needs to be in place for manufacturers to maintain their devices and, in the process, engage more with upstream communities? How can users not lose access to their devices or simply need to stop using them because they're out of support? What are some of the mechanisms through which upstream developers can get compensated for their widely-deployed code?

These were some of the questions I talked about with Harish Pillay at FOSDEM in Brussels in early 2020. Harish is a Red Hat colleague of mine; he's Head, Community Architecture and Leadership, and works out of out Singapore office. He has a long history with open source and this is a podcast you'll enjoy listening to if you have any interest in these topics.

Listen to the podcast [MP3 - 20:10]

Wednesday, February 12, 2020

Podcast: A Taste of Research Day, Brno 2020

Red Hat Research connects researchers around the world with Red Hat engineers, customers, and partners to move great research ideas into open source communities. We recently held a European Research Day in Brno, Czech Republic with tracks covering Data-Intensive Science and Software, Security and Privacy, and Code Analysis and Verification.

Check out this podcast for short interviews with three of the presenters.

  • Kit Murdock, a PhD student at the University of Birmingham covers Plundervolt: Pillaging and Plundering SGX with Software-based Fault Injection Attacks
  • Red Hat's Uli Drepper in the Office of the CTO tells us about Avoiding Bad Decisions and Heuristics
  • Martin Ukrop, a PhD candidate at Masaryk University, discusses his research Observing Developers Interacting with TLS Certificates
We encourage you to check out the videos from the entire program as well as the Red Hat Research Quarterly for more information about Red Hat Research.


Listen to the podcast [MP3 - 19:01]

Monday, February 10, 2020

Podcast: Open Cloud Testbed with UMass Amherst's Michael Zink

Cloud testbeds enable research that requires peeling back cloud computing abstractions. In this podcast, Michael Zink from the University of Massachusetts at Amherst talks about Mass Open Cloud (MOC), datasets on the MOC, FPGAs, and the testbeds being used to support the systems research community.

Zink spoke at Red Hat Research day in Brno, Czech Republic in January 2020 where this podcast was recorded. He gave the keynote for the Data-Intensive Science and Software track in which he presented the NSF-funded Open Cloud Testbed project.


Listen to the podcast [MP3 15:29]

Thursday, February 06, 2020

Podcast: Tidelift's Luis Villa on license experimentation and collaboration

As we cover in this podcast, recorded at FOSDEM 2020 in Brussels, questions about open source licenses and what restrictions developers may impose on the use of their software are having something of a moment. In this podcast the co-founder of Tidelift, Luis Villa, talks about why these discussions seem to be coming to a head today and offers his thoughts as to what issues we should be thinking about. In the show notes, I link to a great blog that Luis wrote recently as well as the location for videos of some of the debate-style and other discussions that took place in the Legal and Policy devroom at FOSDEM (still in the process of being uploaded).

Links:



Listen to podcast (MP3): [13:04]

Wednesday, December 18, 2019

Podcast: Martin Mao of Chronosphere talks open sourcing internal projects

Chronosphere provides a monitoring platform, built on M3, for large-scale environments. Martin-Mao is the co-founder and CEO. In this podcast, he talks about the journey of taking M3 from an internal Uber project to a product offered by an independent company, Chronosphere. What do you do when a project outgrows its original role as an internal company project written for its own purposes?

He discusses topics such as:
  • Why it can be important to start in open source from the beginning
  • How to ramp up contributors outside of the core team
  • Aligning business goals of those governing the project with the goals of the community
  • The challenges of open sourcing an internal project.
Links:
Listen to the podcast [MP3 - 12:14]

Monday, December 16, 2019

Podcast: Idit Levine, founder of solo.io, at Kubecon

In this podcast, we covered API management and service meshes for microservices--and why moving from a monolith to microservices can be challenging. We also got into the business side to talk business models around open source and the creation of communities.

Listen to podcast [MP3 9:33]

Tuesday, December 10, 2019

Podcast: Open source sustainability with Manifold

In this podcast, recorded at Kubecon in November, Manifold co-founder Matt Creager and VP of product Leah Rivers sat down with me to talk about bringing down the barriers to open source commercialization. Manifold powers marketplace infrastructure to connect developers with APIs, tools, and services. We talked about how we might make it easier for developers to build sustainable businesses, even small ones and some of the ways we could make it easier to package and sell software.
Link to podcast [MP3 24:15]

Monday, December 09, 2019

Podcast: Open Governance with Chris Aniszczyk of the Linux Foundation

Chris Aniszczyk heads developer relations for the Linux Foundation. In this podcast, recorded at Kubecon in San Diego in November 2019, Chris takes us through:

  • What open governance means
  • Approaches to open source sustainability (and the problem with donations)
  • Governance best practices such as naming
  • Why projects should have neutral homes
  • When you should (and shouldn't) use a contributor license agreement
Links:

Listen to the podcast: [MP3 23:52]

Monday, October 21, 2019

Podcast: Matt Broberg talks Developer Relations

Matt Broberg is technical editor for opensource.com. In this episode, he takes us through what Developer Relation is, how to measure its value, the "soul" between the data points, and some of the ways in which DevRel roles can vary from company to company.



Listen to the podcast [MP3, 17:37]

Subscribe to Innovate@Open on your favorite podcast app.

[Transcript]


Gordon Haff:  Today, I'm here down at All Things Open in Raleigh with Matt Broberg, who's the technical editor of opensource.com. We're here today to talk about Developer Relations.
Let's start with something pretty basic. What the heck is Developer Relations?
Matt Broberg:  I wish that was as basic as you asked. To attempt to put it into a quick summary, Developer Relations is an organizational unit, a business unit that is tasked with relating to developers. I think that's the quickest way to summarize it. You might hear job titles of people in DevRel as we call it that are developer advocates or developer experience engineers.
There's a number of nuanced roles that end up falling into it. It is a bit of na ew definition of an organizational unit. There's a lot of discussion on whether it rolls into one of the traditional ones or if it lives on its own. Yeah, DevRel's a thing.
You'll see job titles for it all over, but exactly how it fits is very much up for discussion.
Gordon:  How is this different from where we were historically because obviously companies like Red Hat, Microsoft, and others, have certainly had developer programs for a very long time. Are things different today?
Matt:  I think they're wildly different. My understanding of the history of this is we have this sort of rise of the developer evangelist in the technology space. These people that were on stage speaking and other companies started to notice the impact these people had to the association with their brand, the excitement around the open‑source projects around the brand.
With time, evangelism became less of the goal. It was more advocacy around participation in either the open‑source or even closed source communities of a given project.
With respect to developer relations, the need for it has risen out of the inability for the traditional marketing and traditional project manager to relate to a developer and be able to communicate in their language the value they'll get from using certain technologies. I think of it, kind of similar to how DevOps has risen out of the need for Dev and Ops to communicate differently.
I do think of DevRel as something that the project management side of the house and the marketing side of the house are trying to find this new need and DevRel's filling it.
Gordon:  If somebody is doing DevRel, or of somebody's thinking about what Matt just talked about, that's sounds sort of like something I might want to do, how should they expect to spend their days?
Matt:  The day will depend on talking to the team that's hiring you about what it is and looking at the job description closely. DevRel does seem to be a catch‑all for a lot of different things in the developer community.
For some organizations that means hitting the talking circuit and being at a lot of the most innovative and highly networked events around the industry and whatever vertical you're in. A lot of DevRel folk in the open‑source community are here at All Things Open.
Writing articles and other kinds of content. Creating podcasts, like we're doing now. Those are some of the outputs that tend to be measured.
Others, it's about code contribution and being a shepherd of a particular community. Let's say you're a subject matter expert in Python and our project requires a Python SDK. We're looking to get more Python adopters. You, being the person that speaks to that and contributes to the code and helps curate that contribution, is more of the core facet.
I wish I could give you a solid single definition. I can tell you for sure you need to talk to somebody about what it is. You'll do some weird, but wonderful, combination of speaking and listening and coding and not coding [laughs] .
Gordon:  One of the things you said does talk to some of the background of people who might go into DevRel. You're suggesting that for some they might be doing quite a bit of coding, which obviously implies a certain interest in and some degree of technical background. Whereas there's other people at DevRel who really don't consider themselves technical.
Matt:  That's a good note. I tend to look at it as something where coding, that is the core part of your responsibility when I design a DevRel organization, which I've done a couple of times. It comes to finding that right mix of coding and talking.
For many organizations they just need somebody who can talk to somebody who is a developer. That has a lot more to do with your knowledge of the community, knowledge of the ecosystem, and less to do with how much time you spend pushing code to GitHub or to GitLab.
I appreciate that. There's no gate‑keeping here. Regardless of your background, you can be inside in DevRel. You may need to learn some of that software background to participate. It's really: Are you able to participate and communicate to the degree that aligns to whatever your business needs out of a developer relations organization?
Gordon:  You mentioned measurement in passing a minute or two back. You just gave a talk here about measurements and metrics.
I'm in an evangelist role myself. Fairly different from a developer relations role. I have struggled with that same issue of metrics and measurement. Part of it is that the stuff that is easy to measure is often the stuff that isn't very important; you hope it is a proxy for something that's important, but is really challenging.
Whereas a metric of how much do developers respect us as a company...you can do surveys and the like, but that's still kind of a hard thing to really suss out.
Matt:  Yeah, finding the soul between the numbers is always this thing. I keep trying to struggle with it because it's fun, and it's hard, but the way I approach it these days is I think of the different things we could measure, the tally marks and peanuts that we're counting.
That's raw data that we're going to feed into something, but when we're communicating our value, that's actually a business motion. We have to talk about what metric, which tends to be an aggregate metric, something that is providing more value than just, say, the number of talks I've given.
I think the number one thing that somebody in a DevRel‑ or evangelist‑type role as well, it's the stories you can tell after. Who have you influenced, what did they do with that information, what is something that happened that wouldn't have happened if you participated?
Telling that angle, which is not measurement. The core measurements, there's a couple that we can talk through that are really fascinating, but I think at the basis of it, there isn't a standardization. There's a need to know what you're being measured against, and whether that is how many people show up to your talks or how many people are contributing code to your open‑source project.
I've seen both, and they're both valid DevRel, they're just wildly different needs.
Gordon:  I think historically, there has been this tension or conundrum in, perhaps particularly open‑source ‑‑ though it's certainly not exclusively oriented towards open‑source ‑‑ towards looking at things like how many times something has been downloaded, for example.
Which has been super easy to measure, and probably indicates something. If the number is zero. That's kind of bad no matter how you slice it, but it also doesn't really tell you, for example, how much it's being used, how engaged the users are
Matt:  I really love this point, Gordon, because I don't think data has an opinion. We imply a lot of opinion from data.
Downloads, for example, you're like, "Is downloads good?" Probably yes, to some degree. Maybe it's bad if people have to keep re‑downloading the same thing in order to get it to run.
It might be a problem with your uptake for whatever project you're working on. I tend to think of downloads in some sort of time series. It's like downloads per day or downloads per week, downloads per individual, how many unique downloads can we have.
Now we're getting to data and parsing it in a way where we can tell a story behind it, because data on its own is just the raw bits. The stories can actually be really harmful if we don't use it in the right way.
A more common example, people talk about page views, because a lot of us create content. How many page views are you getting for what you're doing? Page views feels really vain, it's a vanity metric at its heart, but it can be a really good standard if other organizations you work with use page views in a way.
I can say when I write an article on opensource.com, I can get 10,000 page views to the right audience of developers, but we may have to spend $5,000 to get that syndicated to an expensive platform that we're paying for.
My free path is meeting that same measurement. Now I'm talking about business value. I'm adding value by writing here as opposed to money funneling there.
It's when we can find that comparison point that we go from a raw and maybe uncomfortable, maybe seemingly useless metric, to something that's like, "That data is transforming into a metric that will add value."
Gordon:  As you mentioned, time series, changes over time, can also be very valuable. Whatever you think of page views, for example, as a metric, if it is going up steadily month to month, quarter to quarter, year‑to‑year, that is probably a good thing.
Matt:  Yeah, exactly. It's fitting into that larger narrative of what's changing, why is it changing, can we find that if we push something, if we poke this that it goes up or down, so that we can test our causality with that change. That's fun too, but that's pretty advanced.
It really does come down to, can you measure the things that are worth measuring? Then can you find the metric that people are actually going to care about? A pitch, they don't pay me to do this, but Bitergia is the place to get your data in there for everything from Slack and Discourse to GitHub, GitLab.
It all aggregates it and starts to identify individuals and see their path through your community, so seeing the correlation of data is easier than ever with the tooling.
The storytelling is just as hard as it always been. We have to keep doubling down there and that's why I keep talking to people like yourself about it.
Gordon:  It does seem in general, we have the data points now and we know how to correlate them in things like that. As you say, you can still risk over applying certain types of vanity metrics, as you put it, GitHub stars and that kind of thing.
But we do at least have that data, so we at least have a baseline where we can be thinking about how to measure effectiveness and how to really direct people so they are more effective and take actions in that way.
Matt:  There's a wonderful phrase of, "Just be careful of what you measure because if you incentivize it, you will achieve it." Which means that even though these metrics, if these data points are a proxy for some point of value. GitHub Stars, my understanding for many is that it's a proxy for popularity and popularity's a proxy for monetization. That I can make some money on this if there's a lot of people that star it.
But if you start focusing just on stars, it's not going to necessarily correlate with the monetization. You still have to have the understanding of what's the business flow to make money, because open‑source is not a business model, as we're well aware.
So understanding like the flow all the way through from the raw data you're using to the outcome you're presuming, we all have a responsibility to inspect that and take the time to understand the impact.
Gordon:  Well, going back to downloads, for example. If you really focus in on downloads and you certainly saw that a number of years back in a lot of cases. If you make that your metric of success then the answer is, well, we advertise and let people know and encourage them to download and give them gift cards if they download and everything, and then our job is done.
Matt:  You nailed it. Now you're done, so exactly. There's a corollary to that. The bad of that is that you can miss the soul of it. You can miss that people want to be happy about what they're downloading, they're not downloading it because they're pissed off. There's a nuance there, of their emotional state as they do so that you can't really grab there. The question is, how do we pivot our metrics?
You start representing happiness as opposed to just raw downloads. The other thing is maybe you're right, maybe if downloads are a great metric, maybe you go to fewer conferences and save the money and give out some gift cards. That's a valid strategic move based on data informing it. That's why data can be very informative but it can't choose for you.
The data doesn't have an opinion on your strategy. You have to have that. There's a lot of work to be done in our space to inform and share common models that are working, because all models are wrong, but some of them are quite useful. It helps us communicate value in the same way as sales can talk about their sales qualified leads leading to closes. We need that in community work that leads to happiness as well.
Gordon:  There is the idea of the funnel, if you would, with developer relations as well. If everybody knows about your product, project, software, well, maybe building awareness isn't something you need to focus on. Maybe they are aware of it but they're also aware of how horribly hard it is to use. Maybe in that case you should be focusing on documentation, training seminars, that kind of thing.
Matt:  It's funny, because anyone who has done this for a bit, we all know the right things to do. The question is, "Can you justify it with your model?" Absolutely, I think, applying a sort of marketing funnel strategy to this, Mary Thengvall who wrote the book about DevRel as a business model is super brilliant. She's talking about DevRel Qualified Leads or Community Qualified Leads, same idea of having a single unit of measure of handing off individual contacts throughout the business.
I think it's a really cool metaphor that we might want to use strategically to be able to say, "Hey, this is who we bring in." Sometimes we hand them over to recruiting to get hired and sometimes they go to sales, sometimes they go to products.
That's the unit of measure so maybe that's part of the answer. I'm not totally sure right now but I do know it's going to be unique to your business .
Gordon:  Sometimes there's a discomfort with these kind of metrics because I think, for many of us, our first reaction is, "Oh, look, we're talking at a conference. We're writing a lot." Just trust us.
We're doing good things out there. The fact of the matter is if we don't all focus too much on the page views instead, so finding that, I think you called it the soul in between those really is challenging
Matt:  The soul between the data points is really hard to capture. If I could, I would completely drop all this data hunting stuff that I like to do even though it's kind of fun for me and just focus on the soul stuff like the things where somebody feels included and loved and cared for and that it's part of their identity to be part of the community.
But I've seen time and time again when you focus just on that, you end up losing funding. It's just a fact of business, and capitalism which we can't reject.
We have to accept where we're in in our system and build the system on top that will justify it, the models on top that will justify it, I'm with you, I want to find the sole in it. I think that we still need to get a strategy to quantify it so that we justify it ourselves.
Gordon:  Thank you, anything else you'd like to add?
Matt:  I really enjoyed talking to you. If anyone interested in how they can learn to write about their technology skills, maybe if you are an engineer and you've never done this before, I coach people as part of my job at opensource.com. Reach out, open@opensource.com. I'm happy to work through learning how to write your open‑source stories.
Gordon:  And even if you aren't a full‑time writer like I often seem to be, I would really encourage people to do this thing. It's a great platform for you to get better known. It's fun to do at least I find it fun to do. It's really a way to share, to let others know about your experience as always to get involved in new things.
Matt:  Definitely. We try to make it a very exciting community to be a part of so we got everything from cool swag to really great people we'll connect you with. Yeah, reach out.