 The game I like to play is called Cats and Dogs. So what I do is I send you the following. So I'm thinking of two animals, a cat and a dog, and these two animals make different sounds. And on a count of three, as a collective, once I say three, we're all going to yell out an animal we choose and the sound it makes. So if I say one, two, three, and you think dog, make a woof, or if you think cat, make a meow, and if you don't know, make a moo, whatever. So that's how we're going to start these things. It's going to be a little fun. It gets the fun out and it's weird. Yeah, it's super weird. So ready? One, two, three, woof! Great, now we know who's type A and who's type B. I won't tell you which. All right, product manager and open source, or APM's primer on leftist software development models. Nobody laughed, but I think that's really fun. So, a bit about me. When I was younger in college and high school, I did a lot of electronic music production. Synthesis, low-fill oscillators, drum machines, weird stuff. I was in a trance in electronica. That was kind of my foray into technology. Like, wow, I can get fast feedback moves off of the synthesizer by twisting a bunch of knobs. My mom used to drop me off at the local guitar center and then go food shopping and be like, great, you're good? I'm like, great, yeah, she's good. So, you spent a couple hours there and came back. Yeah, sure, so I'm in Nassau County. So, I'm an alumni of a couple different companies. I've had a story history. You can look me up on LinkedIn and be like, wow, he's worked a lot of places. So, now with Google Earth, yay! So I have a little bit of an open source background myself as kind of an engineer. I like to think of myself as an enterprise read me expert, really good at reading. But yeah, I maintain open research, which is an open source research platform for customer research. So, you scratch your head and be like, huh, I feel like I'm a little biased when it comes to the product I'm building and I want to figure out how to tap other people and use tools and resources. Where do I get started? Open research! So, those are all free. It's in public domain and I try to make it as open as possible when you have open formats and all the fun, hippy stuff that we expect. And then ZSH completions, if you're interested in Shells or ZSH or more obscure Linux stuff, I'll have to talk to you about my ZShell. So that's a project that I work on. And also a resource for you. One of the things that I love to do is meet new people in New York, have conversations, networking as part of this game, but so is learning. And I'm an avid and obsessed learner. So if you're interested in learning or teaching or just hanging out, grabbing a whiskey or a coffee or coming to the Google building, you'd just be like, wow, it's so big and you have so much food. That's totally, my contact will be later and you can come hang out and we'll talk tech. Great, so important stuff, right? So if you fall asleep during this talk, which is totally possible because it's like seven at night, here's what I want you to think about, really dream about. So the first thing is going to be this idea of time to value, right? When we think about value in software and we think about value in these experiences that we are really creating, right? It's real simple. We want to make sure that people have good experiences. And we don't want to take a long time to get there. So we want to reduce our time to value. If you look at open source models, that kind of works, right? Because what you're doing is you're increasing the ability for more people to add features, you expand surface area, and you reduce your time to value, right? A great example is Linux, right? Linus Torval built Linux a while back and now Linux runs on this TV. And it also works on this projector. Well, there's not a projector here, but there was in probably Linux, right? Linus didn't build for a projector, right? The surface area was opened up because you had people who realized, well, I can reduce my time to value by grabbing Linux, expanding it, and opening up the surface area, right? Tremendous. Layers. So if you work on a product, or if you use a product, the layers underneath your product have open source layers. This is partially one of the reasons that we're in this kind of like, I don't know what I'll call this, technological revolution right now with all these amazing new products coming out. The hard stuff is being solved and being built upon, and that's where you see this idea of layers. Underneath the hard, there's a ton of open source, and I'm going to go through that later. If you're awake, you'll see. The next really is relevance, that it's open source inside your products. Developer, make me a random number generator, right? Like, these are solved problems that people have already done at open source, and by using these, we can make, you know, big things happen. This is a new idea that I'm starting to play around with, and I was telling somebody today, and she's like, yeah, this is not a good idea, but I'll explain it to you. This idea that we as product managers and really as people that move technology can create shared mental models that we can share with people when we're collaborating. And by kind of stating, this is how we're going to think through a process. This is how we're going to think through this conversation in a room like that for an hour or two. By setting boundaries, and by creating a shared mental model, putting on a whiteboard and be like, this is how we think through, it reduces a tremendous amount of inertia that we usually have in these meetings, where people will raise their hand and just throw something out. You're like, no, no, you're in the wrong path. So the question is how do you keep people on path? So this idea of shared mental models is just something I've been thinking about a lot recently. So I'll try to like expound upon that while I go through the deck. It's new, it's not really part of the deck, but I think I can weave it. Cool, what is an open source product? So like some people will agree or disagree with my definition, but hopefully it's a product that is open source. I can read the source code, it's available. I can download the source code, I can build it on my own. There's this sentiment of you would even say bare bones product. I know the stuff that's going on under the hood. That's open source, pretty straightforward. They also contain licenses. And licenses are like probably one of the most important things in open source. Because if you use an open source product with a license that could hurt your product, be in the safe. If you use an open source product that allows you to move more freely with a more simpler license, it works in a better way. Kind of simple there, but I'll go through that later. These are high levels. And we say product, but maybe we mean project, kind of the same thing. What's the difference? A product is something that you pitch to someone that sells, that people use and ultimately kind of makes money. A project is tooling, something that is more less money-driven. It's a project. It's kind of the thing you make in your garage and you share with other people. Projects can totally turn into products. And products can probably turn into projects, but usually it's projects to product. Ah yes, this is one of my favorite sites. So just look at that picture for a second. Think about what's there. And let me drink some water. So it's 1980, maybe 1983, 1984. And the parents bought you a 10D computer for your 18th birthday. And it comes to your house, $1,000 machine, and you're like, this is unbelievable. How do I get started? Well, I can subscribe to one of these magazines that basically provide me source code. And I can build one of these games and write it myself. And this was totally a thing back in the 1980s. People did this. They subscribed to magazines. They got source. They compiled it on their computers. They had their own running games. This is GitHub, right? This is code distribution 40, 30 years ago. Unreal. Punch cards are kind of similar. You can even touch the code in a punch card, right? It's weird. So when you say open source, you can say, well, it's unpopular for the last 10 or 15 years. SourceForge was one of the popular ones on the internet. But ultimately, this is kind of one of the first massively driven distributed open source models. And once you've built this code, you can change it. If this is a game you can increase the lives. It's an integer, right? You can change the value. So when we think about open source, you go down to the lowest common denominator, which is open source code. That's it. It's just magazines. So are they a new thing, right? 1980s magazines, Linux. We spoke about Chrome. Chromium is an open source browser, and Chrome is built on top of it. Android, right? This TV is a Sony TV underneath the hood. Android. And they're underneath Android Linux. And then Pigeon. So the reason I put Pigeon on is because it is a chat product, right? It's one of these old school, like, AOLs and Messenger chat products that have been around since the year, like, I don't know, like, 98, 99. And what's so interesting about computing, and I got to think through this more, there's something there, is that we can either consume, we can create, or we can communicate. And that's kind of it, right? That is software. That's the internet. We can communicate things, we can create things, or we can consume things. And Pigeon was so novel because not only was it an open source communication platform, but it had a plug-in framework. So that means that anyone could create, like, a plug-in for any service. So it'll go old school for a second, AOLs and Messenger, ICQ, MSN, IRC, right? All these are old school ways of communicating in chat. This is pre-slag, right? And you could build plug-ins for this. And that was open source. So anyone could do it. Crazy idea. Like, super cool. And is it a new thing? Sort of. So, like, this is the crazy thing, right? Commercialization of open source is really what we're experiencing right now. It's in a couple of different directions. The first direction I mentioned earlier, right, is these layers, right? Simplifying the hard stuff, making it easy to build quickly and simply on tried and true things. But then, and then you have infrastructure that's open source. You have open source scalable projects like Kubernetes or things like Cloud Foundry that are open source totally and allow a developer to move faster and build products quicker, right? And these are open source, I go as far as to say, at scale, right? You basically have, there was an article recently that talked about open source has standards, right? Because when you move so quickly, it's really difficult to find a standard. Standards take a long time to build. IETF, W3C, all these different standards, standard building places that build these long documents that basically turn into architectures and infrastructures that last the test of time, right? HTTP is a standard, right? HTML is a standard, right? HTML5, that's a standard. But those are great, but those are really like low level things. So the question is, how do you move faster? How do you create standards quicker? Maybe you just throw code up. You say, hey, it's a thing. It does this thing really well. Is anyone interested in surface area expansion? Do you want to provide more value? Do you want to be an engineering multiplier? This guy named Stephen Wally, he worked with Dr. Nose and Microsoft. He was quoted saying, there's no such thing as an open source business model. It's really just engineering multipliers. So I thought that was pretty novel. I get ahead of myself. There we go. So Europeans love open source, right? I saw this article and I was like, this is amazing. The European Union is basically like, we want open source government solutions. We want it because it allows us to move faster. We want it because it reduces our surface area. It also allows us to not rely on a vendor for things like security challenges, right? Like, security is a thing now. It's obviously going to be more and more of a thing. The more we have these devices and applications that kind of run our lives, open source security, in my opinion, always gives you an opportunity to really vet code. If you want to understand what's inside the box, open it up, all right? And you get updates. Pretty compelling for free. And this is like probably one of my other favorite slides. HoardWorks is now 21. I checked it earlier. I don't want to replace the image because I was like, I don't want to replace it. But there's market value here. Red Hat, the company that kind of survived the Linux desktop battles of the late 90s still around is killing it in the market, right? People are going back and saying, hey, what are servers running? The gray beard engineer in the back goes, oh, it's Red Hat. What else are they doing? And suddenly they're doing containers and Docker and all these interesting things around Kubernetes and building scalable systems. And they're all open source, right? And they sell services on top, and they sell plugins on top, and it's knowledge that's added value. And they're doing great work in market. And their philosophies are actually pretty cool, too. And HoardWorks makes a flavor of Hadoop, right? They took Hadoop, which is just a crazy, big data processing system, and they put services on top of it and awesome stuff on top of it to make it easier for people to do, right? How do you process data at scale in a large corporation? You might use a HoardWorks product, but underneath the hood, open source. So where do we use open source? It kind of led to this, but like, hey, it's in your phone. It's on within your iPhone. And it's in your browser, right? This is all the open source stuff in your Chrome browser that in its license asks for a credit. If your license can say, hey, if you're going to use this open source software, we need to be credited. There you go. This is cool, right? So when we make websites, like I said, we always use open source projects. D3JS is an amazing graphing framework. You have graphs and data-driven imagery out, right? Totally open source project. JavaScript library for manipulating documents based on data. You can make any of these by pushing in some code and some digits and then you get a beautiful picture, right? This is free. You just need a good engineer to figure out how to use it, but this is free, right? It is crazy. A crazy idea where years ago you would have companies that would charge five or six figures for projects like this. This is Facebook. React is a front-end framework. It's a UI framework that Facebook built a couple of years ago. And it has gotten so much acceptance by the front-end development community that it has become literally the standard. Recruiters look for this all the time in resumes. My friend is a... I have a couple of friends that are front-end engineers. They all use React. That is the thing they use. It's developed by Facebook and it opens source. And they support it. They accept requests to make changes in code. And it scales and it works and it's free. It's crazy. So, okay, we understand what these things are and how they exist. Who participates here? So, we really have two players. We have a community, which effectively has resource time. And then we have a customer, right? Who has the cash money to make things move. So it's so interesting here is that these two things these two different containers are so hard to grow. And they use completely different methodologies to grow. Growing your customer base with open source and your community base with open source not only requires different resources, it's a different mind. It is a different way of approaching the problem. In one case, it's all about knowledge. It's all about control. It's about surface area. It's about giving end-users a voice. And in the other case, it's really about satisfying a customer need. Right? Why do we make products if it doesn't satisfy a need? Sometimes you do because it's cool. And that's awesome, like we learned something. But generally, products are there to satisfy a need that we want to build on. Right? And that's pretty compelling. Another thing that I think we don't really think about is this idea that I can actually have an influence on a product before. We don't have that today. Consumers don't have that ability. Like, I can't knock on Sony's door and be like, you know, I really don't like the way you allow me to change channels. I want to try and go instead of a square. That doesn't happen. But this allows you to do it. This actually allows you to change the products that you use. That's unbelievable. And not just because we're consumers, but because it gives the companies a direct feedback loop. There's two ways to do that. One, you can say this is what I want. And the other way is to say this is what I want and I'm going to do it myself. Right? That's an insane way to think about consumption of experiences, creation of experiences. It's not normal. People make things, we take them, and we use them. But now we've changed the cycle. People make things, we take them, we make them better, and then we give them back. And then more people do it. You create this feedback loop that's insane. It's a different idea. And I've always found that probably the most compelling one of the most compelling aspects of open source in that I have a voice. Nobody might be listening, but I have a voice. I'm not stuck with some customer service reference like, thanks for your feedback. You sound. I actually can log into a repository and say, hey, I think you can make this better and here's how. Or do the work for you. That's novel. So this is Richard Stalman touching everything and turning it to code. Like that. Stalman wrote a lot of old philosophy documents on open source. What if everything in the world was open source and readable? What if we lived in a world of open source technology? What would that look like? How would we exist? Could we even consume that? Could our brains handle that? Like my Facebook feed went up and it was all crazy. But now everything around you is transparent. I could touch a wall and figure out what materials were made. It's insane. He's kind of crazy. But also, he predicts a lot of really interesting stuff like these techno bureaucracies. He predicted a lot of things that would happen in software where you'd have companies that take open source and then close it. Kind of killing the project that's still letting you throw. It's like a project like Java. Right? Sun created Java. Oracle bought Sun. And then Java as an ecosystem totally changed. Enterprise Java. It really reduced their resources on the open source. But Linus wants to rule with a loving a loving that iron this. Because ultimately this project is so personal that it is an expression of him. Software can be an expression of himself. It's my vision. It's my pattern. It has the same code patterns that I use for development similar to thinking. And that's super interesting too. Because when you think about open source you start to look at structures and systems and the way people think about the progression and fall of information. You are literally getting down to the atomic level of logic. You are setting a mental model for your community and how they think relative to your project. There's that mental model now. These are the best practices that my project uses. This is how my brain thinks and I want you to think like that. If you do, you can give me a code. Weird. But that's not true. We all deal with things differently. But this starts to change that. It starts to dictate thinking patterns and thought patterns and best practices. It's crazy. It's crazy. Crazy. As a corporation maybe Google, maybe Facebook do this thing I want to do so I have this motivation. Right? I want to grow awareness. These resources I want to standardize. Surface area. There it is. These are my wants. The reason I want to do that is I want to develop a community. Because when you look at open source practices one of these practices is having a list of things I would like to help with as an open source maintainer. It's a to-do list. Community might come in and see a to-do list and be able to get involved in a project with a feed web by executing on it. You don't work for me but now you kind of do. Or you are interested in the same subject as me and now you can help me grow my project. Right? You want to ship products faster. The faster I get something out, the faster I get food back on it. The faster I get something out, the faster I get something back on it. And as an organization this is one of my favorite things to talk about. I want to something so I can something. Now when you look at open source maintainers and ownership you see a lot of different players. We talked about the BDFL. Other spectrum of that, we also have the organization. We have Mozilla. We have Apache. We have these organizations that shepherd open source projects that help them succeed and basically gain traction in market share. But they also create governance. They give you structure for accepting requests from other people. They give you structure for communication and guidelines. They help you create a board. They also hit up enterprises that want to have a say in the product. So people like the Apache foundation or the Linux foundation will basically create a group of corporations that are using the product that's open source and they'll say put some money into the project and now you get a spot on the backlog. They facilitate this openness but they also get feedback from the users and a better understanding of where things belong in the backlog and they can build this great product. Pretty interesting. They want to attract other corporations to get funding. But also, you probably want to reduce the single point of failure narrative. If I'm a single corporation, that's kind of terrible. My project could be at risk if I feel my project built. Who's going to take this over? Organizations like Apache, Mozilla and so forth reduce this risk. Makes sense. So where a project resides, this is always my favorite. You cross out these two things. One is this war. I'm like, where should source code be? Microsoft is like, we're not doing it anymore and Google is like, yeah, I guess I'm doing it better. And that's where all these projects are now hosted. Microsoft and Google and Facebook, all the big players host other open source projects on GitHub. Pretty compelling. I always point to Go Mix and Glitch. They are a project out of FogClean. FogClean makes FogBugs that also made Trello a small site called Stack Overflow. This is a cool project that basically allows you to take open source and remix it. Right now it runs Node.js and that's the kind of source code you can use. But if you're interested in grabbing another person's source code and not worrying about running it on your desktop, it'll run in the cloud for you and you can change it. You go back to that narrative of the magazine where you pull source code down and they change it and it gets spun off. It's really a cool project. It's a great idea. And then you have these things called package managers that are basically language specific ways to pull source code. So if you're writing Python or if you're writing PHP or if you're writing Java you have a package manager that handles the libraries, which are generally open source. These are your dependencies underneath the hood that your language will use. They're abstraction layers that make stuff easier. So how does a product become open source? So once it is how do you keep it from falling over? So this slide is all about pointing to the concept of ask questions. Look at how other people are doing things. Who should own it? What license should they use? What's my governance model? This is really up to you as the individual to decide if you're a BDFL or an organization or a corporation. What type of community do you want to create? There's lots of different types of communities. There's communities with boards. There's communities that are fully open source and everyone has an opportunity to speak. Hard to scale. There's communities where a corporation kind of runs the project and community is really users that give them feedback. But they're not open to code changes. There's lots of different styles to creating these models. Business models. Pure play open source. Just buy me a beer. This thing is free. No worries. Do your thing. Community open source. This is the foundation narrative. The patch of Linux, Mozilla, so on and so forth. Subscription. Hosted software as a service. WordPress does this. Ghost, Sandstorm, which did this to failed. They didn't do it in a way that's scaled for them. And then multi-license open source. So at core, it's free. But there's closed source value at. You take something like distributed cloud platforms. That sounds really complicated. Great, because it is. But the problem is getting those things spun off and scalable in a big cloud. That's really hard. What you see now is a lot of companies taking these big projects and saying, here's the source code, here's how you set it up. But we're not really going to tell you how to tune it or make it scale. I have this thing that's really hard and I have this other thing that's the same thing, but it has an installer and that costs me some money. Great, it's an installer. I'll double click and run through it and I'm good to go. So that's the idea for open source core, closed source value at. You have organizational ownership benefits. Why do I want to patch you to hold this thing? Why don't Mozilla do the things for me? What's the value of giving my storage code to an organization? Ultimately, there's less headache. It removes the narrative of subjectivity and you can build and not worry about all the other stuff surrounding it. It lowers your time to value. You want to build something valuable? Great. You're not interested in creating a governance model. I don't care about the people. I care about the product. It depends. Some people want it and some people don't. People have different ways of viewing it. This is the narrative of governance. Where we govern the project in a specific way. That really big takes the project's future. You look at two sides of the coin. We have a chaotic environment with a ton of stuff coming in. It's super innovative. We have a very high level of risk but very low inertia. Versus a very structured and process driven environment where we have a very low level of risk and a tremendous amount of inertia for innovation. Risk and inertia have different ways of flowing. Inverse relationships. And then we have licensing. Cool. This is a cool topic. If you're sleeping, try to wake up. We have two types of licenses. On the left side which is very extreme you can think of this as a very liberal way of looking at things. You basically say I don't care what you do with my code. I don't care. You take it, you can distribute it, you can print it on papers and throw it above New York City on New Year's Eve. I don't care. You can make a product on it and charge for it. Fine, you can change it. I don't care what you do to it. That's a very liberal way of thinking about things. It's open. It's free. I don't care. I have no narrative. I have no opinion. Then you have a very conservative and structured way of thinking about licensing. Which is you have the source code but if you're going to make a change you have to bring it back to the original product. Anything that this source code touches also gets the license. It's called the GPL New Public License which last slide. So let's say I have a product and I want it to actually be successful. What do I do? So there's lots of different ways to make open source projects successful. Contributor license agreement so that people going in know the rules. Super important. Empathy. I didn't talk about that at all. Empathy is a big buzzer of it. It's like everything that I know I learned in kindergarten. Like being empathetic to your project, to your users but to your contributors. The people that are giving you feedback is super important. So we have all these great ways to do that. I think this is my favorite which is this idea of learn and teach and teach and learn. If you teach other people and you make the world a better place and you give people feedback and you're open and honest with your thoughts you make projects better. I point to this because this is so awesome. This is Rob. He worked on Cloud Foundry with me and he had this. These are just two links. There's a heart that's green and a heart that's broken and red. We're thinking of doing something. Is this okay? Or is this a terrible idea? All I have to do is click and I can give that feedback. He has this routing tool like an app that does the rest. That's really easy. It makes these people the contributors and the customers give them a voice by clicking a link. That's pretty cool. You create that feedback loop, that pipe that gives people an opportunity to provide an idea. So thanks. That's me. That's Richard Stahlman playing a flute. That's my Twitter. That's my LinkedIn. That's my Gmail. Please feel free to hit me up below or tell me how awesome or terrible you felt my fiber. They're on SlideShare as well if you want to take a peek. Thanks to all the people who helped me. Thank you for having me. Can we ask you time for questions? I got a thumbs up. If anyone has any questions, I might have answers. There's a lot there in that question and I'm going to repeat it back just to break it down. What's the incentive for me as a developer to open source my code? What's the incentive for the companies? Great question. Let's answer the first question. As a developer, what do I want to do this? What's my incentive? I'm trying to find a good analog. Artists create because they feel compelled to create because something inside them gives them a spark and they use that spark to light things on fire. That's a pretty heavy analogy, but they create. Developers developing writing code is a really creative process. It is cerebral. A lot of people think it's they call it going into the zone. Your sense of reality changes when you develop software. When you write code and you have a full picture of understanding of a mental model that you've created. A lot of people want to share that and the same way artists want to publish their art. I think that's probably the first thing. I'm not going to call it ego, but I think it's partially like I feel strongly and I want to share with other people. With that said, if you look at this is part of the narrative that I've been weaving, the surface area, I think this thing is great but I don't know how projectors run or TVs work, but I want people to help me get there. That's really as a creator their incentive. Corporations want to give engineers platforms. They want to make people feel good about working there. They want to give opportunities to people who are working there to say your code and your project is relevant to the rest of the community. We should be exposed and we should have an opportunity to start getting feedback from other people. We create feedback groups. We reduce our risk. We have communication. That's why corporations I think are ultimately very compelled and as long as the project has an appropriate license and is done in a way that is legally sane lawyers are like what's going on? But once you've found that safety space it tends to work really well and marketing teams love it and recruiting teams love it because it brings talent in. Because I can find out who created and who added to a project and be like hey, I see you like our project and you want to work on our company. You're talented. You already understand how we think and how we build software. Marketing teams like it because it's warm and fuzzy we're giving back to the community. We're putting effort in and not asking for too much fat. As a business you have these two things that ultimately it's an engineering multiplier. If a project is really good and we don't have enough resources internally at an organization to keep building it like I said surface area exposed to the community knock on a couple of doors and be like hey, what do you think? Pretty interesting. You don't see ads for a lot of this stuff but I expect eventually we're going to start seeing ads on websites to point developers to a certain source code project. Why not? Spend a dollar or get 20 lines of code. Generally that costs like $150 an hour in New York. You know, an investment. Yeah, I think you have to define the narrative control what that means, right? Because if you use GitHub or a lot of other open source platforms people can fork the code they can take the project and create their own project but the question I ask is what's the threat to somebody forking? If it's horrible and dangerous maybe that's not a good fit for the community maybe that's not a good fit to put in the open. I think you have to ask yourself a question and also why is control important? I think another question you should ask is what are our metrics? What does success mean for this project? And what are the negative success? What are our goals? What are our anti-goals? If it's taking up a developer it's like three or four hours of developer's time every day maybe this isn't like maybe we need an alternative approach here and GitHub specifically allows you to turn issues off and allow pull requests that should be turned off. If you're in an organization which is a little apprehensive you can say listen we're going to start as an experiment keep everything open and see what happens I was in an organization who was terrified of open source and I said what's the worst case? What's the anti-pattern? What do you not want to happen? Great I'm going to track it and send you a weekly report and tell you what's going on and we put it out and there was like three people who commented and one of them found a bug and I went to the executive team like listen we saved ourselves about five hours and the single person pointing out a bug we have created an engineering resource from this project and it took me 20 minutes to answer a couple of questions okay there is benefit but that's a whole other thing in itself how do I create an open source transformation in my company that's kind of like not into that and the narrative is it's an experiment let's talk about metrics what are our goals and anti-goals and who is responsible that's always very important right any others? yes the gentleman in the blazer okay yes what did you mention before sure when we look at product goals and the things that this thing that we built does right what does it do we have to ask the question can it do more and do we want it to do that thing now when you're talking about blockchain and cryptocurrency and these kind of systems that is the core of why people fork right they want it to do something different from its intended goal and I think that's where you look at the narrative of forking over all in projects where people fork and change and they continue to commit and build new because they have a different philosophy right you have put an amazing stake in the ground but I want to move that 20 feet away and it is anti of your philosophy it is not the thing that you believe in hopefully people who fork have conversations and say listen I know you're doing XYZ but I think A, B and C are also pretty awesome would you be interested in collaborating and building that some groups are like no that's crazy that's out of spec that's not something I'm interested in fork so I think that's where it's very hard to say there are predictors but I think predictors are downstream from resources and philosophy how opinionated is your approach to creating the product if you have tremendously strong opinions people might fork because they might disagree I think that's the way you look at it that's a good question