Made by 
Made by
January 24, 2019
DevRelCon founder and CEO of Hoopy, the content agency for the developer economy.
Simon Phipps
Twenty years after the coining of the open source label, what does it mean to developer relations? Everything, argues OSI president Simon Phipps, who explains why software freedom is at the very core of developer relations in his talk at DevRelCon London 2018.
Just to give you a little bit of history while I’m plugging devices in over here. I was doing a job in 1995 that I think would be called developer relations today. I was IBM’s Java Evangelist starting the Java Technology Center in 1995.
And that made me wonder, you know, what exactly is the origin of developer relations? Where did it come from? What are its influences? And I’ve been trying to work out the answer to that question a little bit. So, the question has to be asked. Where did developer relations come from?
What is its origin? And if I had to answer that question in just in a snap response, I’d say, it came from the free software movement. And now, I’d like to try and explain why I think that to you. Some people think that DevRel came from monkey boy, and the famous performance in 2000.
But it came before that because I was already doing the job there. I’d already been doing it for five years and so that was not the beginning. Now I just said that, did it come from open source? Well, open source wasn’t coined until 1998. And again, I was doing the job in 1995.
But I do think that it came from this movement. And I’m going to try and explain to you a little bit about what open source is and I’m then going to try and suggest to you that it’s good to connect back to open source and look to it as a place to find lessons to learn for your job as it evolves in developer evangelism, developer relations, however you want to term the activity.
So, origins first of all. Now, I’m the president of OSI. I am on brand, I’m told by my board, and, you’d expect me to want to differentiate with free software but I want to tell you that open source is free software. Free software started in the USA, it started in the, if you want to go right back to its origins, probably in around about 1977.
And that was the time when Bill Joy, who is the gentleman over here, Bill started out working on a set of tools that went with AT&T Unix. And he developed that into a suite of tools that began to be distributed by the university where he worked in Berkeley in California, and came to be known as the Berkeley Systems Distribution or BSD.
And as time went by, AT&T turned out to be a toxic bedfellow, and Bill and his team in Berkeley gradually implemented more and more and more of Unix. Until at the beginning of the 1980s, Berkeley Systems Distribution was not just a set of tools, it was also a Unix Kernel that did the same job as AT&T.
And you could tell it did a great job because AT&T went on to sue them for breach of copyright. They survived that case because they hadn’t breached copyright. What they had done was re-implemented APIs. And it’s a good job they aren’t around today with Oracle to sue them. And so Bill’s whole philosophy was, “Here is my cool stuff, please use my cool stuff. Do more cool stuff, just don’t bother me, okay.”
And, the BSD license that came up with that distribution embodied that spirit of sharing the cool stuff around and sharing whatever you think is cool with everybody else, and really not getting on anybody’s case. Now the gentleman on this side is Richard Stallman. And at the same time as Bill Joy was doing all that cool stuff with BSD Unix on the U.S. West Coast Richard Stallman on the East Coast was getting frustrated with a new printer that had been delivered to MIT, because he discovered that for the first time, he couldn’t make the printer work the way he wanted it to because he hadn’t been able to get a hold of the printer driver so that he could modify it to print pages the way he wanted.
And that was his inspiration to start the GNU project. And GNU as you all know is a recursive acronym. It means good news, not Unix. And the GNU project was devoted to the ideal of software freedom. The ideal that the users of software should be in control of their own destiny. And that, as a prerequisite for that, was having the source code that created the software.
And in those early days of the free software movement, the way you got hold of all this software was by asking for a tape. And that was was famously, and we can maybe talk over our coffee later, about how James Gosling came to have a fight with Richard Stallman that led to the writing of the GNU General Public License. But to get the software you had to have a tape, you were probably working in a university lab, you were an insider, and that changed as time went by.
But the fundamental freedom remained defined. Free software is an ethical construct. This quote from Richard Stallman explains that free software is software that makes the user free. Now that word “free” turned out to be something of a problem. Because you see, as soon as you start talking about free software to anybody who speaks English as a first language, they think you’re talking about money.
They can’t get out of their heads not having to pay for the stuff. And so as during the 1990s, we moved into an era where the Four Freedoms needed explaining to business, we began to discover that business leaders got confused when you explained this stuff to them. And so we coined a new phrase to mean the same thing.
Bruce Perens has told me that open source is just a marketing campaign for free software. Please, never be under any confusion and ignore anybody who tries to tell you that it is two separate communities. Free software is open source is free software. They’re the same thing and they operate around a set of freedoms that allow people to be in control of their own use of the software.
In 1998 when that term was coined, we started the Open Source Initiative. And the Open Source Initiative does some useful things for the open source movement. We standardize our open source software licenses, for example, and we help communities come together across the divide. We have a lot of affiliates who join OSI in order to collaborate with each other.
So it’s quite a lot of background. And it would be really good if the slide progressed as well. Don’t you love technology? There we go. So, free software was something that worked really well in the era of tapes but in the era of the internet we began to find, we had to talk about something else to help people who were not initiates into the ethical system to understand what was going on.
And so, the term “open source” let software users and software developers promote software freedom at work as well as at home. And that began to lead to the phenomenon of open source communities forming. Prior to that, most software had been constructed on mailing lists in a very relaxed way, with patches being circulated.
But as we got to the beginning of the 2000s, we began to find that open source users gathered together to share their skills and experience and also to share their knowledge about deploying the software. What had happened was that we had created a world where people were able to practice liberty in the context of commerce, just like the Statue of Liberty does in the context of the New Jersey docks there. They’re in the same posture, but they’re actually about something a little different.
So, I’d suggest to you that this is the origin. This is where it first became necessary to work out how to deal with developers, how to advocate for software, and how to manage communities.
As people began to come together on the Internet at the beginning of the 2000s to use free software, even though it had been a pre-existing concept for 15 years, that the inception I would suggest you, is the beginning of the 2000s. Software freedom set users free to use software for any purpose.
But then open source let communities form and let them come together and begin to cluster. And then out of that, developer relations began to apply structure to free communities. And I would suggest to you that the things you practice, whether you know them or not arise out of the conduct of those free communities.
Now today, the communities you’re working with, you may not think in terms of a free community but I’d suggest to you that the behaviors that work in relation to developer activities still flow from the same principles. So we’ll talk a little bit about what it is that leads to community management being an effective skill.
Open source succeeded, I’d suggest because of three big top-level headings, and that bottom-level heading, I split into three, so I do cheat. First of all, crystallization of consensus. Secondly, the idea that the licensing is a multilateral activity. And thirdly, that communities are safe spaces.
So first of all, crystallization of consensus, this is just a quickie, really. If you or your employer are ever tempted to create a new open source license, then this describes the process you would have to go through. I’ve made it particularly hard to read and complicated because I’d really rather you didn’t.
I’d suggest to you that creating new open source licenses is a deprecated behavior. Updating old ones is just about tolerated, but if you look at the trouble that MongoDB are going through on the license review list at the moment, you will realize that maybe that’s something you don’t want to do.
If you do decide to do it, I strongly suggest you get expert support and advice from somebody because it is not at all straightforward introducing a new license to the license review list and coming out with your integrity intact.
But what does OSI do? OSI is not the high court of open source, we’re rather the speaker of the house. We run a consensus gathering process where we let everybody have a voice. We watch for that consensus gathering process to quiesce. We crystallize the opinion that arises out of it, and then we record it and remember that decision. And that has been a magical thing for open source software because at the beginning of the open source movement, there was a lot of confusion about what actually was open source.
But by creating a standardization process for licenses, people are able to proceed on the understanding that everyone agrees that the Apache License is an open source license. And so, if it’s under the Apache License, I can probably use it as long as my employer lets me. That wasn’t the case in 1998 with the new Mozilla license. The new Mozilla license in 1998 was probably a free software license.
It probably promoted software freedom, but there was really no way of reaching consensus and memorializing that consensus. And OSI brought in a mechanism for memorializing that consensus. This is also the reason why if you decide that you’re going to make a new open source license, you really should respect that community consensus.
Now, you would expect me, representing OSI, to tell you how important it is to involve OSI and respect the outcomes but the reason I’m telling you that it’s not because I want to aggrandize OSI, but because I want to warn you that OSI sums up the collective majority opinion. And if you act against OSI, you’re probably acting against the majority consensus opinion, which is a known negative behavior for developer relations people. And so I suggest that you involve us early, and that you respect the process.
Licenses, I said that multilateral versus bilateral. Now, if you’re in a business and you talk to your lawyers, they will tell you that licenses are…they’re like a truce between warring parties. They decide where you’re going to be allowed to kill each other, where you should be safe.
And they are in that sense, a bilateral agreement between two parties. Now an open source license is not a bilateral agreement, an open source license is a multilateral agreement. It is the constitution of a community. It is not intended for litigating, it is intended for defining what the permissions, the rights, the freedoms are, that everybody needs in order to collaborate.
And as such, this is another reason why we don’t need more of them. Because most communities have already got a license. The context in which your product or API operates is probably a set of communities that already have licenses. And so we don’t need another one. You just need to respect the licenses of the communities you work with because those are their rules.
That’s their constitution. That’s what they have agreed are the freedoms that they need. So open-source licenses are the multi-lateral consensus of the permissions and norms for a community. That’s why they exist. They’re not there as a legal document primarily, although they are legal documents, they do get litigated, and you don’t want to be in a position where you have caused that to happen because that is also bad for your reputation and your developer confidence.
And then I said, safe spaces. Now open-source communities are meant to be safe spaces. And they’re safe spaces on several levels. The first level on which they are a safe space is they mitigate the ownership of control points. Out of the creation of a new piece of software come many control points through which you could reach into controller community.
And an open source project removes the obstacles to commute to control. The classes of control, I’ve tried to put them into a little kind of an acronym for you at the bottom there, that the classes of control are copyright, registered trademarks and patents. And open source does its level best to mitigate all three of those through licensing, through contributor agreements, and through community governance.
And if you are in a community where you’re trying to leverage any of those control points, then you are going against the consensus of the community. I’ve got some lawyers on my back at the moment who are trying to persuade me that OSI never said patents were bad. But I don’t need to say patents are bad. Patents are bad for developer communities because they make developers feel unsafe.
And because they make developers feel unsafe, they go somewhere else or they fail to contribute or they fail to deploy. And an open source community’s all about safe spaces. Now I believe this is an extensible concepts as well. Whatever mechanism you believe you should be applying to control a community, probably comes at a cost of developer confidence and developer trust.
And at several points in my career at IBM and at Sun, people have suggested that some controlling behaviors come with no consequences, that the company needs to do them to protect itself and there are no consequences, such as contributor agreements, for example. And I would suggest to you that’s never true. Anything which applies a control point that applies a point where somebody will one day have to ask for permission, will inherently reduce developer trust and inherently reduce the effectiveness of the community that you’re trying to promote.
Finally, business models. Open source does not have business models. Although that was a popular meme in the first decade of open source: open source doesn’t have business models, you have business models, open source has communities. And in an open source community, there can be people with many different business models.
And the role of an open source community is to isolate all those business models from each other and stop them messing each other up. And if this isn’t true of the community that you’re trying to structure, then you’re probably doing it wrong. Now, that’s an unpopular statement, I know. But there should be room in any community for people to make money in any number of different ways.
And if that involves competing against you, you might be doing it wrong. You might want to work out how to create businesses that don’t compete with your community. Cultures of contribution.
Now open source communities are communities of contribution, and I want to say a few things about these. People talk about open source as giving stuff away. And that’s a thought pattern that arises out of that word “free” being misunderstood. Open source isn’t about giving stuff away, open source is about spending your IP to buy collaboration. Instead of investing your IP in a revenue return, you invest your IP in a collaborative community.
And if you think about it that way, if you think about a community as an investment of your IP, it doesn’t seem so bad to license it in a way that it’s freely available because it turns out that when you do that, you get good returns. Contribution results in other people maintaining your code for you. I often wonder whether Facebook would be able to afford to maintain React if they didn’t have a huge community debugging it for them. I suspect that they would find the burden very hard.
If you don’t contribute, then you are sentenced to forever maintain the code that you wrote. You are sentenced to always have to maintain your last innovation. And as life goes on, and you innovate more, your maintenance burden grows. I always used to keep a tape with my first COBOL program in the bottom drawer of my filing cabinet from when I worked at Unisys just in case the bank ever needed me to go back and work on it.
And that’s the way you are if you don’t contribute. You always have to keep a copy just in case it becomes your problem again.
One other thing to say to you is that contribution is inherently inclusive. Now, inclusivity is a fundamental of communities. A community is a place where everybody is able to contribute according to their means. And if you find that there are not people contributing according to their means, again, you’re probably doing something wrong and you need to find out why.
Is it that you’re not creating an environment where people feel free to contribute, maybe they feel threatened, maybe their employers feel threatened by your business, maybe your community is one that has a particular tone that leads to people not participating? But contribution is inherently inclusive. And, when it’s not, then you know that you’ve got something that you need to go and diagnose.
So, let’s sum up open source for you. This is the logic flow of open source. The first thing I worked on at IBM was a reuse project, code reuse. And I have to tell you, developers don’t want to reuse code, they would much rather write it themselves. Okay. But reuse definitely beats re-implementation. But collaborative development beats reuse. It actually makes developers want to reuse when they’re able to develop collaboratively. But to develop collaboratively, you need to make sure that people don’t have to ask permission to contribute.
You have to make sure that contribution is inclusive and permissionless or permission granted in advance. And software freedom, open source, guarantees those rights. It gives you the freedom to use the software for any purpose, the freedom to study it, the freedom to improve it however you want, and the freedom to share it with whoever you wish. And those four freedoms empower you to engage in collaborative development with whoever shows up, inclusively.
And then OSI approval guarantees you that those freedoms are present in the project. And so that’s why developers tend to check whether you have an OSI-approved license before joining your community. It is not because they’ve got some fetish about the OSI, but because that’s what makes them confident that your community will actually include them, will actually accept their contribution, and will actually allow them to satisfy their inherent needs to make a profit or to make a social contribution or whatever the reason for showing up is.
The rules have changed, really. From when I started working in the industry, it was all about keeping code private. Today, if you’re keeping code private then you’re the exception, you’re not the rule anymore. That’s because the real value of open-source is letting people innovate without needing to ask first, and then let others benefit from and maintain the innovation for them.
And I’d suggest that you, as a specialist, in the nurture of developers, go with that flow. That you encourage people to be in inclusive, safe spaces, safe both for their person, safe for their career, and safe for their business advantage because that is the lesson that open-source has brought us.
When we make places that are safe in those three ways, they are places that flourish, and that grow, and develop more. And when you cut across you’ll discover that it’s hard. When you do want to introduce a permission step, when you do want to tax certain degrees of use, those are the points at which you start having to pay the price yourself as a company.
I would go on a greater length for you. In the full one hour version of this, I’ll run through all five of those points for you. But the one that I wanted to emphasize for you briefly, because you’re all cloudy people, is, I want to encourage you to code for cloud freedom. You see, we’ve been talking about software freedom, that was the last 35 years, it’s unclear to me how that applies to the next 10 years, to the world of cloud computing.
And I believe that to guarantee the of freedom of developers in the cloud era, we have to do certain things. I think we have to create distributed applications that are interoperable, and we need to avoid creating centralization. Now that’s very painful because that’s probably close to the heart of your business model, but I’d encourage you to explore business models which actually can be federated, that can be decentralized because throughout the history of open source and free software, I’ve seen that users really are made much more happy by having the freedom to leave.
When the user can leave, they tend to stay. And when the user knows they can’t leave, they are always unhappy, they are always agitating, they’re always looking for an alternative. So I’d encourage you to do that in the cloud era as well, and come up with solutions that are both federated and that also allow for deployment on new platforms.
So to conclude for you, open source, software freedom, I believe is at the core of all successful software projects today, and I believe it’s at the core of the practice of developer relations. I believe that if you’ve got questions to ask about how to handle a particular new situation, go back to the Four Freedoms.
Ask: “How can I give my users and my developers the freedom to use, study, improve, and share the code?” Because the answers to those questions will almost always be the answer to the problem that you’re looking at. And, I would say that, really, what you’re doing depends fundamentally on open source, I’d encourage you to come participate in open source communities.
Modern open source communities welcome people with all kinds of skills. They welcome people who develop code obviously, but they welcome people who translate, people who document, people who engage in marketing, people who run events. We want you. I want you to come join The Document Foundation and work on LibreOffice with me with all of those skills, and every community would love you to join.
If you come volunteer in open source communities in addition, I mean, it’s like doing the day job at the weekend, I know, but if you come do those things, those experiences will guarantee you a successful future in developer relations. Thank you very much, and a happy birthday to open source.