We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Frenemies in FOSS: How to deal with Charter Conflicts & competing efforts

00:00

Formale Metadaten

Titel
Frenemies in FOSS: How to deal with Charter Conflicts & competing efforts
Serientitel
Anzahl der Teile
39
Autor
Mitwirkende
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
They say imitation is the sincerest form of flattery, but it sure doesn't feel like that if your project gets disrupted by another FOSS project. FOSS is one of the best ways you can work to make a better world, but the launch of a new project that runs parallel to one you've worked on for years can be really disheartening. What if they're piggybacking on your brand to get halo from your project? The Right to Fork is great, but what if they're better funded or sucking up all the funding you used to rely upon? This talk will discuss how to evaluate a parallel project launch and strategies you can employ to make sure your project doesn't falter in the face of unexpected competition.
QuellcodeQuick-SortKonfiguration <Informatik>Besprechung/InterviewComputeranimation
Open SourceTermProgrammierungQuick-SortParallele SchnittstelleMereologieAuswahlaxiomProjektive EbeneIntelWort <Informatik>Computeranimation
VersionsverwaltungAuswahlaxiomPunktInformationSichtenkonzeptInhalt <Mathematik>Translation <Mathematik>QuellcodeProjektive EbeneOrdnung <Mathematik>Office-PaketMultiplikationsoperatorOffene MengeInstantiierungVerschlingungARM <Computerarchitektur>VerknüpfungsgliedSchlussregelBitVerschiebungsoperatorSoftwarePlotterOpen SourceDebuggingPatch <Software>Gesetz <Physik>Disjunktion <Logik>Regulärer GraphGruppenoperationComputersicherheitCodeFlächeninhaltSpezielle unitäre GruppeDistributionenraumFormale SpracheTypentheorieHyperbelverfahrenAppletZweiFreeware
Produkt <Mathematik>Projektive EbeneReelle ZahlOpen SourceStreaming <Kommunikationstechnik>Twitter <Softwareplattform>PlotterCoxeter-GruppeVersionsverwaltungMultiplikationsoperatorCodeAuswahlaxiomMessage-PassingElastische DeformationQuellcodeExogene VariableTotal <Mathematik>Offene Menge
MultiplikationsoperatorMereologieProjektive EbeneEnergiedichteFrequenzOpen SourceDatensichtgerätKonfiguration <Informatik>Fortsetzung <Mathematik>Strategisches SpielKeller <Informatik>
Open SourceQuick-SortPortabilitätTwitter <Softwareplattform>Offene MengeThreadKonfiguration <Informatik>DruckspannungGemeinsamer SpeicherMultiplikationsoperatorProzess <Informatik>Strategisches Spiel
Open SourceProjektive EbeneOffene MengeProzess <Informatik>GruppenoperationPunktwolkeSuchmaschineExogene VariableStrategisches SpielVersionsverwaltungOffice-PaketStrömungsrichtungDienst <Informatik>UnternehmensmodellMultiplikationsoperatorMathematikRichtungElastische DeformationComputeranimation
Open SourceProjektive EbeneObjektmodellStrategisches SpielMatchingCodeÄußere Algebra eines ModulsNatürliche ZahlSoftwareMultiplikationsoperatorMomentenproblemQuick-SortFreewareMinkowski-MetrikVersionsverwaltungMereologieDienst <Informatik>Automatische HandlungsplanungEndliche ModelltheorieCASE <Informatik>Patch <Software>Installation <Informatik>
Open SourceGruppenoperationFortsetzung <Mathematik>MultiplikationsoperatorUmsetzung <Informatik>SystemplattformAbstimmung <Frequenz>MereologieStrategisches SpielParallele SchnittstelleDigitalisierungDienst <Informatik>BitQuick-SortUnternehmensarchitekturMomentenproblemStützpunkt <Mathematik>Computeranimation
Prozess <Informatik>Gebäude <Mathematik>DigitalisierungAbgeschlossene MengeOpen SourceSystemplattformFormation <Mathematik>Vorlesung/KonferenzBesprechung/Interview
Kollaboration <Informatik>Besprechung/Interview
QuellcodeVorlesung/KonferenzBesprechung/InterviewComputeranimation
Transkript: Englisch(automatisch erzeugt)
Thank you so much. Hi there, folks. I am speaking to you from Austin, Texas, because yesterday was my husband's birthday, and he asked me to come to Texas for his party, and I had to say yes. So originally I was supposed to be in Berlin now, and hopefully next
year I will make it, because I love this conference. So I don't know how many of you recognize this graphic. This is from a magazine that doesn't exist anymore called Mad Magazine, and, you know, it's pretty obvious what's going on here. These people are pretending they like
each other, but they're actually plotting to kill each other, and unfortunately there's more and more of that in our world. So I decided to do this talk to sort of look at what your options are if this starts to happen to you. So without further ado, oh, right, I'm using this
thing. I forgot. What is a frenemy? Well, this is somebody who claims to be your friend but is working against your efforts. I used to work for Intel, and they used a lot of neuro-linguistic programming on their employees, of which I was one, and one example of that was the use of
the term fellow travelers, in quotes, which they used to describe both competitors and partners in an effort to not seem to be a monopoly. The problem with fellow travelers in the commercial world playing into open source is they often have a lot more money to spend than the open
source project, and they can make it look like a much more interesting place, therefore, or they can just try to take over the main project, and this is an example of frenemy behavior. Another one, which is more in keeping with the open source world, is when former community
members want to go another way. That's why forking exists in open source licenses is so that people who have been past contributors can make another choice, try to get the thing to work the way they think it should work, and those are friendly might be the wrong word,
but let's say those are allowable forks because that's part of the open source ecosystem. Another example, however, of frenemy behavior that I'm seeing more and more is advocates who sow fear, uncertainty, and doubt about your open source project, whether or not they're involved in a parallel effort, so sort of gratuitous naysayers,
and especially influencers can really wreak havoc when that happens. Okay, so sorry about the almost unreasonable type. I apologize about that. It looked better last
night when I was working on it. Okay, examples of unhelpful actions that frenemies might take. First of all, hostile forks. That's a fork where, in the parlance mostly, you as a community were not looking for your code to be spun into another effort,
but it's happened, maybe because some of the community members wanted to do something different, maybe as a disruptive move by a big player. There's lots of reasons why this happens. Some really well-known examples of this, OpenOffice, which now lives at Apache,
and LibreOffice are examples of a hostile fork where the parties in the two communities don't really play together nicely at all, and there's been substantial shift. I was involved in the OpenOffice project originally, and I've said publicly I believe that LibreOffice is winning
that battle, but it's definitely a battle, so that's a frenemy action. Another one would be Sun's work with Java back in the day, which was not open source, and Apache Harmony, which was an effort to create an open source version of that language, which Sun saw as a
hostile fork, and they might be right because it was funded by IBM and Intel, so anyway. Another one is ownership conflict. We see this a lot in areas that are going to be commercially viable as open source projects, and when I say commercially viable, I mean they're going to generate revenue for the entity that is applying hostile fork rules,
so there are some projects at the Linux Foundation that are only there because the foundation spun up a competing effort in the same arena and basically sucked all of the fundraising out of the situation, and so the smaller foundation had to join the Linux Foundation in
order to become whole in their fundraising. An example of this would be Finos. Now I think they're enjoying being at the Linux Foundation, but it wasn't a choice they had. They pretty much wanted to start a charter conference, and the best one I can think of is BSD, open BSD,
and free BSD. For those of you who don't know, BSD, Berkeley Source Distribution, is another version of Linux that's not, I'm sorry, of Unix that's not Linux. It's as old, maybe older, started actually by Bill Joy when he was doing his graduate work at University
California at Berkeley. That community is an old and very well established community, but there was, many years ago, a pretty big schism between the main community and a very small group of security wonks who really wanted to focus on making BSD that was very,
very secure, and led by Theo Durad, they famously spun up another effort and, you know, publicly said, we're not trying to replace BSD in popularity in the world. We just needed to be more secure, and we're going to work on that to the exclusion of everything else,
and we'll try to stay in step with regular BSD, and they mostly do that, but they are the most secure, and interestingly enough, when the Heartbleed situation happened a few years ago, they were the first to have a viable patch, which they then shared with the rest of the BSD community, so it's not always a bad thing. Another example of this would be Gnome versus KTE.
Gnome was one way of addressing a UNIX front end that was open source. KTE was another way. They have coexisted for a very long time. A lot of industry put their money behind Gnome at one point, but KTE continued, and we'll talk about that more later.
Counter marketing can be a problem. We had this issue a couple years ago at Innersource Commons, where the Software Freedom Law Center felt concerned about Innersource as a potential plot to undermine free software, which it absolutely was not. They gave us a lot of detail.
It was apparently a plot that I, myself, and Tim O'Reilly, who is my friend, and Bill Gates got together to perpetrate. It didn't actually involve chips in anybody's arm or anything, but the funny bit was that Bill Gates hates both Tim and I, so that was not actually a thing
at all. But counter marketing can be damaging, especially to loyalists that are listening to those influencers. And then territorial conflicts, another example. So for instance, when I was at Wikipedia, Chinese Wikipedia was famously full of alternate truths to the
truth that is generally accepted in the West. And in Taiwan, they ran a version that was a translation of, say, English Wikipedia, so a much more Western take on things. And the amazing thing is that they were tunneling that content into China. Now, obviously,
if you used that content, you were subject to some problems in China for, you know, looking at the wrong things. But I always applaud the bravery of the Taiwanese and the people in China who adjusted that information because, of course, I think that everybody should
understand each other's point of view. Another example of a territorial conflict would be AWS and Elasticsearch, but we're going to talk about that more in a second. Okay, so what can you do if this comes up? It's really hard to, with a fork, do better than the original project. Obviously, you can throw money at stuff, but there is a first mover
advantage unless the original product is kind of asleep at the wheel and not realizing that they're being imitated or that their situation has changed. So it's important to stay vigilant and understand when this is happening. Time is actually on your side because it's so difficult to get this right from outside the project. It doesn't usually feel that way,
however, and as with engineers diving into code before a design has been validated, it's really common for open source projects to dive into a response when waiting probably would have done them better. Because of the small community that open source represents,
I mean, we're only somewhere less than 10% of the total engineering community in the world, and we kind of all know each other, and everything's transparent. Backbiting is really seldom secret. So when people try to message or influencers go in and try to, you know,
talk about a project behind its back, it's really common for somebody to come to the project's aid and that certainly happened in the whole AWS Elasticsearch thing before Elasticsearch made a choice to change their license. It's definitely happened for us in InnerSource Commons. The
first time we heard about that conflict we were having was a friend of ours rebutting in a tweet stream a presentation about this whole plot thing. And then because open source is public opinion can create real advantage, so it's worth staying connected to the people of
open source, and that's one of the mitigations we're going to talk about. Okay. So here's the first mitigation we're going to talk about. One possibility, and 99% of the time this is the right thing to do, ignore it. There are a lot of hostile forks that aren't going to ever
reach liftoff, and at least for some period of time you should monitor but not expend energy reacting, and that's really hard for open source people to do, but there's lots of data that shows that it does make more sense to spend some time assessing the situation before you react.
Examples of this strategy, the best one I can think of is Postgres and MySQL. So these are old projects. When MySQL was everybody's darling because it was part of the LAMP stack, Postgres looked like the tortoise in the tortoise and the hare, but we weren't sure what was going to happen there. Well, now 20 years later we can say Postgres actually
won. Part of why Postgres won or is currently winning is because MySQL gained new ownership that was maybe hostile to continuing to make it the thing. People didn't trust the new ownership. I don't blame them, but mostly Postgres as not exactly, MySQL wasn't a fork of Postgres,
but it was so adjacent that it was often compared, and they both took the high road. It was really rare for anybody from either camp to knock the other project, and Postgres won in the sense that it continued to improve and continued to improve. Now
Citus Data, which is one of the big contributors, now belongs to Microsoft, like it's gaining interest, but it's still a standalone project, which is important. So anyway, staying friends offers you way more options in fixing one of these things,
so that's my first piece of advice. Next I say it's possible to display high moral ground and gain some traction in the minds of the large open source community, the bureaucracy, if you will, open technocracy. So explaining your efforts superiority,
if you can possibly do it without directly dissing the frenemy, or if you can't do that, that's the highest moral ground you can have. If you can't do that, then something close to that
is the thing to do, but it can still go south, and the best example of this I can think of right now is Audacity and Tenacity. Audacity was a cross-platform open source tool for sound processing that everybody used, and they didn't realize that they were about to be
challenged by a corporate-backed competitor. By the time they figured out that it was a problem that was eating their market share, they didn't have a lot of options. They did a really interesting thing, and if you like a good, there's a beautiful thread about this on Twitter, and there's a couple of articles in the register if you look up Audacity. They wrote a very no-holds
barred post to the open source community about why they were changing their licensing, and then they became acquired by a deeper pocket in a sort of Hail Mary effort to try to get it right. They're not so open now, but they could have avoided this if they'd known their community
better and taken early steps to make it clear to Tenacity that that was a, you know, not a nice thing to do, basically, and I know niceness doesn't always win, but I like to think that it wins more often than you might think. Okay, strategy three is fight, and a lot of people go
straight to strategy three, but I think it's worth spending a minute assessing the situation, which is why I said strategy one should be don't respond, just try to understand what's happening. Okay, so who fights well? My son did this successfully with Microsoft, but it took them
a long time. They had to, you know, allow Microsoft to be a bad player. This is, of course, not in the open source world. Another example of this would be the way that AWS and Elastic Search have done the dance. You know, Elastic Search, of course, for those of you who don't know, AWS
put up a version of Elastic Search in its common services available to our subscribers that was, you know, a fork. It didn't have all the same features as the current version of Elastic Search, and it was only available to people that were paying AWS money
to use our service or involved in that ecosystem. Elastic Search saw its direct business start to fade and decided that they were going to undergo a licensing change to try to forestall that and became a proprietary project. And so this is seen as one of the big issues in open source
now for sustainability is that large cloud companies can really have an influence on the viability of an open project. I think they didn't do enough work to get people behind them because they seemed to think that the fact that they were open made them golden when, in fact,
they had chosen the wrong business model, which is why they were vulnerable. Open source is not a business model, and it's really important to always remember that when thinking about, you know, frenemy action. Anyway, I think that what they did in the long run is going to be good for Elastic Search and maybe also good for AWS but not so good for open source,
which means that there will inevitably be a contender that, you know, does a better job in the clear because that's one of the ways that you disrupt a market like search engine markets. I mean, there's already Solr, and Solr is the second best after Elastic.
I actually think that open office at Apache is doing a version of this that's not healthy. They're continuing to fight and try to be a viable project even though they're years behind now on serving any kind of customer base, and LibreOffice is effectively the only one that's
ever used anymore. It's a quirk of the way that Apache works that it hasn't been attacked yet. There's always one or two people who are really gung ho to somehow make a dent in the Apache open office, and unfortunately, the hang-up appears to be a licensing disagreement rather than
a sincere desire to put out the best technology, which I think is a black mark on Apache, and I do love Apache, but I think they got this wrong. Okay. Next. By the way, I can't see you guys, so if you're hating this, doc, I apologize,
and if you have things you want to ask me, hopefully we'll have a little time at the end. Okay. Another strategy is to just absorb the competition. This, if you have the wherewithal to do this, can be really a good thing. There are lots of examples of this in commercial open source. That's where a company has taken an open source
project and offered services against it or done custom install stuff. This is sort of the red hat model, but then there will be pretenders that want to take up that space claiming that this is not a pure effort. If it's run sort of ethically, it might still be a pure effort.
Cloudera is an example of this. Doug Cutting, who created Hadoop at Apache, helped cofound Cloudera to commercialize it. The Hadoop project at Apache continued to enjoy upstream contributions from Cloudera up until the moment that they shifted
and IPOed and became a bigger concern. Another example would be Canonical and Debian, where they forked from Debian. They continued to feed Debian patches and try to stay involved
there. In both cases, there was an opportunity maybe for one to take over the other. I know in Debian's case, Mark decided early on not to go there because the collective good nature of the Debian community and the academic appeal of it, although it didn't match
his plans for commercialization, was still a precious part of that hole. That gives you an example of a more enlightened version of understanding what to do there. I'm not excusing Mark for any of the missteps he's ever made, but I do think he genuinely tried. I think
that Mike Olson also and Doug Cutting genuinely tried to make that work. Another example is Drupal. Drupal needed an object model a few years ago, and Dries, who is staunchly free software guy, went looking and found an open source alternative
that he could use in Drupal, which is Symfony, and as it fits in Drupal, you know, stuff that works for Drupal that don't already exist in Symfony get sent back to Symfony for incorporation if they want to do that. Because of the size of the Drupal community,
that counts as an absorbing, I think, because it made it into the main code base of a larger project. Okay. We're almost to the end of possible mitigations I thought of. Another one is to just simply study what they're doing. Why are they winning? And then improve.
And improving might include offering to be absorbed. It might include appealing to the community with why your effort is a better effort than the other one. There's lots of room in open source for parallel efforts that appear to compete to peacefully coexist like Postgres and MySQL. It doesn't always have to be a fight. If a fork is more popular than yours, there might be a
reason. But this is my moment to say just a piece about my concerns about what I hear coming from Europe around the topic of digital sovereignty. And because I'm not in Berlin,
I didn't get to hear sort of the latest on all of this from all of you in the coffee rooms. But my concern with what I've heard so far, and I do live in Europe and, you know, spend a lot of time thinking about this, is a lot of the digital sovereignty that I'm hearing is confused with a nationalism. And how that expresses itself is an effort to create services
that only benefit certain groups of people. And I hear these conversations mostly in the it indicates a misunderstanding of what open source says. Open source must be set up so that all the
boats rise. There is no borders. There's no excluding people. And if you're going to do that, then you're not doing open source and you need to stop talking about open source and digital sovereignty in the same exact sentence, I think. Because I think it confuses the issue.
I would like to see more open source happening in Europe. We know that it's mostly coming from small and medium enterprises. They seem to stall in growing, scaling out. Partly because of the way the VC community works or doesn't work in Europe. I think all of this is fixable. I've seen it work in other places that you might not know about, such as Sri Lanka where they
have a very established open source practice and a lot of viable companies that are open source based. But I don't think that what I hear most of the time in these digital sovereignty talks comprehends the fact that you can't create borders in open source.
And that worries me a little bit. So I spend a fair amount of time talking about that. But that's not actually a mitigation strategy for the topic at hand. So I'll leave that off now and come to my end of this part. And if there are questions, it looks like I have a couple minutes anyway to take questions or have conversation if that's possible on this platform.
So I guess I am now asking the people that ran this conference if they'd like to step in and let me know if it's possible to do Q&A and if there are any questions or conversations that people want to have. Yes, I think we have some time left. So are there
any questions, comments, remarks? No? Don't be shy, guys. Come on. This is what we're here for. Let me have a look at our online platform. But I think we don't have questions there. But
let me say that I really liked your closing remarks on this talk about the digital sovereignty. And I feel like a lot of people here in the room feel the same. Yeah, we have to do a better job of educating these basically politicians.
One of the things that the FOSBAC audience in particular needs to realize is there is a vanishingly small percentage of people in the world that know how to build healthy open source communities. And I mean, it is a very rare skill. And we are some of those people. But there aren't enough of us to do an effective job of covering the demand that is
out to happen, is happening, and is about to happen for these skills. And so, you know, in the same way that we worry about frenemies, we need to worry about scarcity and not there not being enough of us to keep them on the straight and narrow and not going down nationalist
roads. Now, of course, they could go that way. China did it, right? But I think the China experiment of the last 10 years in Baidu shows pretty clearly that it doesn't work very well. Because there are entities like Taiwanese Wikipedia. And there are people who get it that
all boats have to rise. So, anyway, that's what I have to say about that. We just need to be louder about it. We need to be consistent and kind. Because they're jumping to conclusions based on what they know. It's really hard for people to understand, especially people who have been steeped in direct competition, to understand how coopetition works, how collaboration really works.
You know, okay, thank you for this great talk. I think there are no more questions from the audience here. So yeah, thanks again. Thank you so much. And I hope to come
back next year and see you guys in person.