 Hello everyone, let's start our next talk, the last one before lunch. Martin Kraft invited Rom to give us a talk about how to better produce open software. And let's keep questions for after the main part of the talk there will be enough time for them. Rom, the floor is yours. Thank you very much. Thank you. I'm so glad to be here, but I said Martin. Martin heard me give a talk in Linux Conf. And he said, oh, you should come give this talk at DevCon. So I thought, oh, this would be so exciting. And I came here, and Matthew Garrett gave it yesterday. So I didn't know where to go from there. So there were two things that I guess I should point out at Matthew's talk. I don't know if he's here today. The first is he was pointing out how he had been contrasting where things were today from where they were 20 years ago. And he pointed out that one of the differences was that he was thinning on top. Behold the future, Matthew. Secondly, he posed a number of questions about why open source wasn't in free software, hadn't met its objectives, which was kind of what I was going to talk about. But he didn't have any answers. And so I'm here to tell you that I do have the answers. So I'm just going to talk about the answers part. And I was going to talk about the software engineering aspects. I'm a software engineer. But he did talk about other problems like revenue and whatnot. And even though I'm not an economist or a financier, I have played one on TV. So I thought we would talk a little bit about that since I had the extra time. Lou Gersner, in his book about the turnaround of IBM, talks, he's called, who says elephants can't dance, chapter 8, I think he talks about strategy. He says, people overrate strategy. The strategy is obvious. Strategy is what everybody else in your industry is doing. It's really the only thing that needs to be done. And so therefore, what differentiates people who succeed versus people who don't succeed is not their strategy, but how they implement the strategy, because this strategy is obvious. So in the case of, what do we do about revenue? The answer, of course, is fixing issue management. So why do I talk about fixing issue management? One of the things that came up, the question was asked when Matthew asserted that Windows was stabler than Linux. Were there any studies for that? So the 2012 Ovarity study, and I've been doing this for a long time, there's a bunch of other ones. Looking for bugs in proprietary software versus free software and found that the average defect density between thousands of lines of code between proprietary software and free software was the same, didn't make much difference, but there was an interesting diversion in the results. And what was that diversion? The diversion is that as proprietary software projects get bigger, they get more robust fewer bugs, and as free software projects get bigger, they get more defects, which is to say, if you believe the data, free software doesn't scale. Fix that. I think we've known this all along. The reason we got here, in fact, is because people have known this forever. In February of 1983, IBM started their OCO program. OCO was object code only. The way it used to work before that was if you had a computer, it came with the source code to the operating system, and it was the way things worked. And IBM was in the business of selling the computers, they didn't mind giving you the source code to the software because it was good for their business. And then if there was a bug or something, you could fix it because you had the source code. And if you wanted to change the behavior of the operating system, yeah, the source code, you could fix it. You could add your features yourself. And people did this for a long time, but as more and more people started using computers, they kind of kept wishing that IBM would do all the fixing instead of them. So they said, IBM, you know, would you fix this? For us, we'll pay you. We want to pay you. We want to give you money to fix the bugs in the software. We think that's reasonable because we don't want to do it ourselves. And IBM said, well, the problem is you've been fixing it. So everywhere we go, people have the software, they have the source, and they modify it. We can't be responsible for the stuff that you modify. We don't know what you did. That would potentially be an infinite cost. So what we're willing to do is we're willing to take your money and fix the software if you promise IBM Institute of Object Code only. We'll just ship you the object code, and that way if there's a problem, we'll fix it. And to this very day, right, that is a red hat model. And we said, and so now the difference between free software and open source software, of course, the free software, people said, well, we know that if you have free software, it's not going to scale as well as proprietary software. So software you're going to wind up with is going to be of lower quality. But we're okay with that because we want the freedom to modify it ourselves. So the freedom is worth the lower quality. And the open source people said, no, no, no, no, no. This open model of software development is a better engineering practice. And it sounded reasonable. More eyeballs make bubbles shallow, and it turns out it's not true. We learned this with things like shell shock and heart bleed, that in fact, all of those eyeballs don't solve the problem. And so again, we've known this forever. I highly recommend this book, the Handbook of Software and Systems Engineering. It came out in 2003, so maybe getting a little dated in sections, but it's a great collection of resources and whatnot about software engineering. So one of the things is, if you think about how many eyeballs do you need to make a box shallow, there was actually some research done on that. It turns out one of the results of research is code inspection is more cost-effective than testing in order to identify bugs. So everybody knew this, and that's why being able to look at the source code was a good thing. But then secondly, the number of eyeballs that the sweet spot is six. That is, if you have three people look at it, you find the most number of bugs for the cost involved, and as you add more people to look at it, you actually just don't find that many more bugs. Not worth it. So it is not true that more eyeballs make bugs shallower. It is true that up to six eyeballs bugs get shallower, and then after that, it stays pretty much the same. So to fix the revenue problem, Gerser's point about what should the strategy be, well to increase revenue, you should charge for something. Or, if you're an overachiever, you should charge for some things. And the first pushback that you get when you talk to crowded people in some place like at Debian is, well, but we're non-profits. This is more about a community thing, and a charitable thing. Why should we charge for stuff? So I took the trouble of Googling for, can a 501C3 charity charge for stuff? And the answer is 72% of charitable income is earned by charging for stuff. Just because you're not trying to make a profit doesn't mean you don't charge for what it costs to do stuff. So what should a free software project charge for? Well, again, if you go back to the GNU Manifesto, back in Stalman lays out when people talk about, oh, this will never work because programmers will be able to make money. No, no, no. There's lots of ways that you could make money. And one of the ways that you could make money is you could charge for distribution services. Another way you could make money is you could charge for feature requests and fixing things. So the proposal is, and it's very simple, is be able to charge for stuff. So how do we do it? Well, the easy one for this crowd starting from the bottom up is every time you do app get, charges your credit card for 99 cents, just like the App Store. And the reason I thought of this, and I don't know if she's here, was talking to somebody, Valerie, about why does that be a new packaging when we had this discussion and it was technical. But at one point she said, well, it's kind of like the App Store, right? It's a signaling. The fact that it's been packaged by Debian is kind of the stamp of approval. Kind of like, whatever, this was the App Store. I said, you made it into the App Store, or the Apple has reviewed it and the same thing for the Android Store. You know, somebody has reviewed it, and so you can kind of trust it. Well, that's worth something, right? So there's lots of ways that you can charge for this. You can charge for the people who are trying to put it in, or you can charge for the people who are trying to get it out. But you should build it in. So apps should have that capability. You know, take one of those open source and micro payment systems and build it into the app. And the thing is, it doesn't force you to charge for stuff. For those people who feel that they don't want to charge for stuff, that it should remain free as in the air, then set your price to zero. That's okay. But for those people who think that, you know, about it's not too much to ask and do that. The more interesting one is maintenance, right? It's charging for bug reports or feature requests. And the solution to that, also equally obvious, but a little history again when I first started using version control systems back when I had hair. There was... The one that we used was called Razer. It's a proprietary system. But what Razer had, a feature that I've always missed ever since because nobody else has had that, was in order to commit your software, you had to provide the issue number against which you were doing the commitment. The theory being, if there was no issue, why were you committing changes? And this is not a reduction of my freedom. If I want to go in and make a change, there's no issue. I can write an issue and say, this is the issue that I have. And by the way, here's the commit that fixes that issue that I had. It closes the loop quite nicely. So the solution for the charging part is if commits have to be associated with issues, so that you have to have the issue in order for the software to advance, charge per issue. And there's a number of different ways of doing that. And again, as for the other one, also your charge could be zero, in which case it doesn't matter, but when somebody files a bug report, it's like, you know, we need your credit card number for this. And when somebody commits a change to it, you're going to get charged. And you can revenue share free software things, so whoever it is that does the commit, gets the revenue. And the best people to implement this, of course, is GitHub. Because, you know, they're collecting people's credit card information. Anyway, a lot of projects are over there, they're going to take a 10% cut, they're going to make a fortune on this thing, just by doing it. But it doesn't have to be GitHub, it could be GitLab, it could be Launchpad, it could be Bizarre, like anybody could implement this notion. And again, so the notion is the capability should exist, charge for stuff. But still, be it charitable work, communities involved, just getting paid for their efforts, and possibly not even getting paid what it's worth. Or a buck, just to weed out people who are spamming you with all kinds of things that they really don't care about. So yeah. If everybody here just wrote an email to GitHub saying, you know, we really like the feature to be able to set a price for what it is that we would like to charge for closing a bug report. And we could set it to zero, and the default could be zero, but you know, it's like, could you add that feature? Then if people I asked they would add the feature and the people could do it. That's not what I came here to talk about. That's finance, that's funding, that's money. I'm a guy, what I came here to talk about was, how do we fix it? So the free software is not of lower quality than proprietary software. What, where did we go wrong in the engineering department so that that shouldn't be true? Just eliminate all dependencies. Software should not have dependencies. Dependencies are bad things. Dependencies are what we used to call PEC debt. If you have dependencies, then your software is of lower quality. And free software, open source software exacerbated this problem, no end. Because in the ancient times, if you had software, and you wanted to do dependencies, so you wanted to include some other stuff, you had to pay for it. So you chose your spots wisely. You picked one or two or three things that you really needed in order to give you a lift and then you used those one or two or three things. When the software became free, we went into Jeven's paradox. Jeven said, you know, paradox is an economist thing. William Stanley Jeven's was a British economist who in 1865 made an observation about the energy markets, which at that time was mostly coal. And the observation he made was as the price of coal came down, people spent more money on coal. If you made the resource less expensive, then people should be able to save money on that thing. So what it turned out is, it was even, so the counter argument was, well, if I have a $100 budget for coal and so I pay a buck a pound for coal and I spend $100 and then coal becomes 50 cents a pound, it's like, I still have my $100 budget so now I buy 200 pounds of coal and that makes sense. But what actually happened was people spent $150 on coal to say like, oh, since it's so cheap it must be a better value I should do more of this instead of the other things that I wouldn't have been spending my money on because this thing is a great value and that's Japanese paradox. And that's what happened with software. As it got free, we wound up using more software than we had used either to simply because it seemed like such a bargain. So unfortunately, I gave you the reference to Andres and Rombach's book because the other great source of information around this kind of stuff was the sea bay set of Hitsburg, the center for the empirically based software engineering which unfortunately is defunct because it doesn't exist anymore but they used to put out a great bunch of stuff. So this is from an article that they put out in 2001 where they were looking at COTS. COTS is a commercial off-the-shelf software but this is basically the notion of rather than writing everything yourself you should use stuff that you can get in the marketplace and so they're talking about proprietary but the principles presumably also work for free software. Like you go out you get a bunch of stuff and then you incorporate it. So CBS, which is actually a recursive acronym, the sea stands for COTS which stands for commercial off-the-shelf. So CBS is COTS based software. It doesn't seem like you need all that level of equanimity but nevertheless. So the point being one of the major observations that they make is that if you have n moving parts when you're engineering a solution then you have n-squared possible interactions and in the best case assuming that they're not three-way interactions which might be coming into play if you just have two-way interactions. So as you add more components to this thing the cost scales super linearly, quite radically. And again he quotes from Garland et al. in 1995 pointing out that the sweet spot is four. Maybe three. So in this article the other thing they point out is by the way is if you're doing what they call glue code which is you take two pieces of software and you sort of go to integrate them and you have to write the code that glues them together and then you look at the effort involved the glue code takes three times more effort per line of code to write than the original code. So if you have like a hundred lines here and a hundred lines there and then you write ten lines to glue them together the cost of that ten lines is like you have to write 30 lines of code and if you wind up doing a lot of glue code you're actually possibly better off not having the components and just rewriting that function yourself because that is less effort than trying to glue them together for a variety of reasons so I recommend them. But the particular paper to read if you're only going to read one thing on this subject use software components only the giants survive by Butler-Lampson. And the reason I quote this one is because you know Basilien Baum did a lot of great work but they're not that famous whereas Lampson got the Turing Award and arguably is the person who invented the personal computing and distributed computing so that's what he got the Turing Award for so it's a great paper besides the start of the paper is at the 1968 NATO conference Doug McElroy proposed that a library of software components would make programming much easier since then many people have advocated and worked on this idea often it is called reusable software though this term has other meanings as well this paper explains why these ideas don't you get a bunch of dependencies bunch of software components and you aggregate them and you try to reuse them and you try to build stuff on top of them alright there's a great deal of literature that says that cannot possibly work and free software introduced Jebin's paradox to encourage everybody to do stuff that way so why doesn't it work his outline is basically well when you go to write something that's going to be reusable it's got to have all of these properties that the software that you would have written had it not been reusable so you want the thing to be portable to a bunch of different environments the person who actually needs the software only needs to run their environment so if I'm using Debian I need my software to run Debian I don't need it to run on Red Hat because I don't do Red Hat but if I'm writing something that's more general I have to worry about that if I want to run a window I have to worry about lots of code and now because that's also complicated now I need a much bigger testing infrastructure a lot more cases and so that gets much more complicated and I need more documentation for how does it work but things are it needs to be configurable differently for different environments and so forth so you wind up with if there's ten lines of code that you need out of a package and you import that package you're bringing along a thousand lines of code that you don't need you're going to solve all these problems that you don't have that somebody else has sort of the thrust of the argument that it's in fact kind of like a 10 to 1 ratio you need to be using more than 10% of the functionality and it turns out most people aren't using 10% of the functionality and that because then if it's a small enough component it's not worth writing the documentation doing all these test cases and whatnot the thing can't survive it's not viable you shouldn't use it and if you do use it you're in for a world of hurt and that's kind of the point of this talk now he does point out that large components are the biggest success in software engineering so things like a browser the renderer like a web browser that's like a huge component or a SQL database his cutoff in this paper which was written in 1999 is 5 million lines of code if it's less than 5 million lines of code and you think you need to include it you're probably done you're probably better off writing the functionality than you thought you would have gotten by doing that because that component isn't going to survive anyway you're going to have to rewrite it when it dies so you might as well start if it's more than 5 million lines of code it's probably going to be useful now again that was 1999 we're 20 years later the hair has gotten thinner on top and so I set the bar today at 20 million lines of code the thing you're looking at doesn't have 20 million lines of code you should just probably rewrite the bits that you need so how do you do that? well Google actually invented a word for this they call it vendering so if you have dependencies vendor dependencies means copy the code into your repo dependency, make a copy in the 1980s this used to be called white box reuse so there's two kinds of reuse when people are arguing about what is software reuse was a good idea black box reuse and white box reuse the black box reuse was oh you reuse this stuff like it's a black box you can't peer inside it white box reuse is get the source code copy it now now you can sort of change it and muck with it because you can see inside the box the white box vendering pretty much means take the whole project and copy it in you don't have to do that one of the things that free software did that you couldn't have done with proprietary software is since you can go and look in the area in fact you need a Shaoan algorithm you don't have to include all the open SSL for that or open SSH you just find the function that does that copy that over and you're done save yourself a million lines of code suck in all these dependencies and then code golf do we know what code golfing is? do we not know what code golfing is? so golf is one of the few supports in which the lower your score the better so you want the fewest number of strokes to win so the idea of code golf which again goes back to the 80s was given that you have some problem some algorithm that you're trying to solve and you're right to code to do that and the genesis of the hacker culture at MIT in the late 70s early 80s you figure out a way to solve this algorithm and in the book he's talking about a similar code and it takes you 100 lines of code to solve that problem then if you look at it for a bit playing golf see if you can figure out how to do it in 80 lines of code same thing it solves the same problem the 80 line of code solution is better than the 100 line of code solution you have reduced strokes you have practiced to the point where you can now sink the putt sink the ball into the hole with only 80 strokes instead of 100 strokes and you can keep playing this game see like what's the smallest number of lines you can do to do this and there are rules as in golf I mean there's certain things are considered cheating like I guess if it were in C in theory you could put everything on one line because the white space turns are optional but you know that would violate the spirit of the whole thing you're really looking for even though people do it in terms of lines it was easier to see when you were doing it as what do you call it a simpler code because then there's a number of instructions but yes the number of strokes if you will so the number of statements might be a better way of phrasing the number of lines of code so my objective here oh there's Keith so Keith is fond of saying about Ramam that whenever Ramam proposes a solution you can be certain that if you do something else that's the right answer so I'm not going to try to convince you that this is the right answer because I know it's the right answer but you're not going to be convinced by me telling you this so the purpose of this talk is to exhort you to try this yourself on one of your own projects so I tried it on one of my own I had this project which I started with 57,000 lines of code plus four dependencies and the four dependencies had transitive dependencies they brought in other stuff and so if you walk the transitive tree and wind up with 12 dependencies that got brought in and I didn't count the number of lines that consisted of but I started with this thing and said let me start removing the dependencies so copy over the bits that I need and delete it as a dependency so this is much easier to do if you're using some kind of language that has typing because what you could just do is sort of delete the import statement and see what the compiler gives you as a error message and that's what you got to know you got to fix or copy over it's a little harder if you're doing something like Python but you know Python 3 now you could type hints and whatnot and there's some IDEs that'll point out things that are defined and whatnot it's a doable thing but anyway so I removed I started removing dependencies copy over the code that I needed and then doing a little bit of golf on them and so I started with 57,000 lines of code 12 dependencies and when I was done I had 57,000 lines of code and zero dependencies software development inherits patterns of software engineering that were developed in a world where there was proprietary software and it was a given that you were not going to be able to peer inside the black box of somebody else's software and so therefore if we're trying to build reusable software you had to do certain techniques and the thing about those inherited patterns is if you live in a world where free software is the default as Matthew said yesterday then those techniques are no longer a problem so what do I mean by that? well let's think about Apache so Apache comes along first it's still the days of proprietary software how do you write software if you want it to be configurable you have to have some kind of dynamic loadable scheme because if I want to add my own features into it it's not like I can go modify the source code I need to have so I'll define API where I can write my source code separately and then have it dynamically loaded so Apache is engineered around that same concept and you have this notion of loadable modules that can be loaded at runtime and the people writing modules don't need to communicate with the people that serve her but of course in a free software world I could in fact go in and stick my functionality right into the source code of the thing I don't need to have that dynamically loadable module and when engine X comes along much later it's also an open source project and it says if you want functionality in there you have to compile it in but hey you got access to the source code crazy and what you wind up with is a thing that has much much less overhead and is stabler and is faster so engine X has been making over the years traction against Apache primarily because it sort of fits the model that another case is this notion of build pipelines I found that and I still find that hard to wrap my head around because I grew up in a world where software didn't get so I'm still struggling to do that and the world of software is changing I almost go back to the ways things were in 1981 so I'm very excited and what I mean by that is I grew up in a world where software source code wasn't in files the advanced software development environments were image based today we would call it a container in this container and you modified the code that did stop and the code was memory resident and you modified the memory resident code to do different things and then when you wanted to checkpoint your work you checkpointed your memory image you wrote out your current state of your container or your VM and then when you wanted to come back to it later you could just load that and keep going and if somebody said well where's your source code it's like I don't know what you mean by source my code is in my image where it belongs and this was true of small talk, it was true of APL it was true of list back in the day so the reason small talk and APL didn't survive is they still work that way APL which just came out last month that's the feature they added they said it is now possible to have your APL code in a operating system text file so I was I thought wow the worlds are converging and everybody else is holding containers so you don't have to keep all of your code do you have no dependencies there's not a whole lot to package go lang took this approach that's kind of pretty much their approach you write your stuff and go it spits out a static executable and then you're done you copy that on the machine that you want to run it on and it runs there's no such thing now you bake it into the executable in fact, what really impressed me was it's the only thing that will produce a static executable on macOS 10 there's macOS 10 in the documentation says you cannot run a static executable so you have to link against the system libraries the system libraries are only made like the equivalent of libc, it's only made available as a dynamic library so you will always wind up with a dynamic viewing executable at a minimum because you need to pull the map and the go people reverse engineered the entire system library they don't use the libc on any platform they generate that internally when you produce your go executable it runs as a static binary even on macOS 10 even though the documentation says that cannot be done and so figure out how to write your stuff with no dependencies I was at the open stack boss the other day they were talking about the work they had to do now they wanted to take 400 python packages which were dependencies of open stack and repackage them because they used to be part of this one package and now they wanted to be part of this other package so this is the kind of stuff that Butler Lampson was talking about you think you save time by doing that and then you have this maintenance burden that requires dozens of engineers working over years to constantly manage this tech deficit you've created because you have all of these dependencies so yes no dependencies, no dependency help that's pretty much the thing so lastly code golf I was talking about doing some golfing what kinds of things am I talking about well they're very simple things really so you can do combining files if you have two files you don't have to have two files make it into one file that's a win because one of the things that happens when you do that is that you can start noticing which things are being never called you can inline functions that are called in one place and what I mean by that is you have something that looks like this you define a function f it does a bunch of stuff then it calls g and you define the function g and it does a bunch of stuff and if you delete those four lines for the case where g is only called in that one place now you would be surprised how often this happens the reason you don't spot it is that you have to find under f like that but if you reorganize the code and start looking for these kinds of things you can actually find that occurs a surprisingly large number of times and then of course once you've done things like vendoring things, code that you didn't write but you sort of copy the whole thing in if you start looking for are there functions here that I actually never call and the answer is yes there are because you suck in this other code it turns out those compatibility stuff you're not using so you can delete that and then you start deleting stuff and then those things call other things which now that you've deleted them they no longer can call it anywhere and pretty soon the whole thing squeezes down so I would recommend studying code golf as the way to proceed so that really was my talk figure out how to get rid of your dependencies start practicing pick a small dependency and that's what I call my assertion is it will not and then once you've actually brought in all your dependencies now you have a code base which is just your code which you understand better and now you can start code golfing that 57,000 line program that I was talking about is now down to 2800 lines and I introduced a bunch so I'm going to have to probably add some more in so I'll probably pop back up to 3,000 maybe 3,500 but given that I started at 57,000 and if you have one tenth of the amount of code you are going to have on average one tenth of the amount of bugs and particularly the pre software world but we know the bigger your code gets the worse your defect density gets as you bring the code size down your defect density goes down and so it's a win, win, win, win time for questions because I suspect that there might be some questions or disagreements or what not and in that case we're not going to have enough time potentially to hold them here but I'm making myself available for the rest of the day to people in the hallway track who want to continue this discussion so I thank you very much for your attention and I will take questions it was quite interesting but I think I disagree a bit because not all defects are equal so for example if you have security issues and just copy the code then you won't notice security fixes to the code that you copied and you will have a deal with security fixes and yourself maybe examples that whatever previous epoch reappears in iOS two years later and so on I guess so you won't find you won't get these security patches that is thank you always the first question and so the couple of ways to react to that one interesting thing about security vulnerabilities is they only go after the ones that are widely deployed so if I were to write and I know you're not supposed to do this but if I were to write my own less worried about security vulnerabilities because what a hacker is going to spend hours, days, months trying to figure out how to find some memory vulnerability in this open SSH library that I'm the only one in the world using it's possible that they might have a big enough company but so that's the first thing is that the diversity makes that part interesting one thing too the thing about I don't want to go to anybody's accident room but I heard in some of the buffs that I was attending is the biggest complaint that people have about devian is it takes so long to get updates and patches and fixes through the whole process so the same argument that can be used for why one shouldn't use devian it's true that it takes longer with devian than with other distros but there are advantages that sort of compensate for that and then think 3 of course is the buff that I was sitting in on was the python buff discussing whether or not python 2 should be moving to python 3 and whether 10 years was long enough time to wait before doing that and the answer is apparently 10 years is not long enough so in that context what I would say is there are a lot of places that have that problem and I don't know that by vendering this software it makes it better or worse so again my encouragement to you is and it might make it worse but my encouragement to you is again practice doing it see how painful it is see what the benefits are see how much code you reduce because again when you including some other package as bugs and vulnerabilities many of those bugs and vulnerabilities are in places that you're not using right so it's you know the windows implementation or the bsd implementation you're using the linux implementation it's different somehow and thirdly oftentimes those bugs are introduced by things like buffer management which is like and the reason that library had to implement buffer management is because since they were operating system agnostic manager whatever the built in facilities work for that it's like oh we have to manage our own buffers and do that whereas if you step back from that potentially you don't need that buffer management code which is where the buffer would have been because you're managing buffers differently for some other reason and lastly the solution to that problem is to use a better programming language that has more software engineering modern support involved so instead of writing the stuff in python if you were writing it in rust or you were using Java you might be better off so yes what I would say is I often get that question from PHP programmers and I don't quite know how to respond it's a potentially valid point but again my exhortation is try it and see if the benefits don't outweigh that risk so I'm not sure how one is ordering here so I do quite a lot of work in Ruby and in the Ruby community vendorizing is a really hot thing and one thing they did is they have their own tool called bundler to manage dependencies and lock specific versions of external libraries containers can be seen as another approach to do the same thing and don't you think that's a real issue that we should just get better at managing vendorization and switching dependencies when we need when we want to instead of just being the victim of version changes yes so that and that's why I had a bit of prepudation to bring this thing up with Debian which arguably is all about packaging lots of dependencies together that's sort of the main activity so what I would argue is in a world where these dependencies couldn't be merged because they were proprietary software and so you had to figure out how to package them that made sense then in a world where you have license proliferation and you had all these different licenses and you didn't know what the licensing regime was to mix this software so you might have incompatibility that made sense and then when you got to a world where there was a large enough base of software using the same programming language now what you are doing is you're building arguments so if you buy the thesis right that having all of these dependencies is inferior to software engineering now what you're trying to do is say inferior to software engineering and build layers on top of that in order to solve the problem where a simpler solution is don't don't do that part first we're going to build a castle in the sand and then we're going to figure out how to put a containment around it so that it doesn't melt and what I'm saying is that's been the approach that we've been taking and we haven't stepped back all the way to Abinicio to say the reasons why we started down this path no longer apply and we should try it and again I'm perfectly happy for you to believe that I'm wrong but rather than try to containerize all of this stuff on top of that is what if you start with whatever the thing is and start figuring out how to remove all the dependencies so when you wind up with this in a program that does what it is that you want to do with no dependencies and does that feel better and it's a skill about diversity means you're like security vulnerabilities are no longer relevant because you're not one enough deployed I would rather I'm not sure that that is compatible with the idea of vandering stuff in but it's like if your code is genuinely diverse fine maybe your argument works pretty well there if what you have is like a modified copy of Abinacel or whatever I could see it being pretty difficult for that to result in enough diversity that you are not vulnerable to pretty much the same attack as the next clone of Abinacel yep so I see this a lot with Forms of Food Make 3 Engine so you have to be committed as I am so when I got into a situation where I needed to tunnel open SSH in my program and I said I said I'm not so that one is hard that was the hardest one that I attempted but I did figure out how to do it so because what happens is when you go to do that and it's like it turns out the biggest difficulty is when you include open SSH and you try to vendor that in and not have any of its dependencies and so the particular thing that I was doing was I was trying to import the C thing into a Swift library so I had to port all the C code into Swift and then I had these sub dependencies which was like BN that actually was the one that took more time than the getting the big num stuff right which actually took more time than getting the crypto stuff right but in my case since I was committed and since I was taking the C code and transliterating it into Swift and then fixing it in Swift so that whatever I wound up with in Swift wasn't the same thing so you're right, crypto code of the ones that you can do are the hardest I do not recommend that you start with crypto code when you start doing this in your application pick one of the non-crypto libraries to do first and second and third but when you get up to like your 10th or 11th time that you're doing this I'd actually go after some of the crypto libraries because it turns out that once you prune away all the stuff that you don't need to do I just needed to do an SCP and so if what you're doing is you're adopting this as a plan to I'm trying to write my thing and have no dependencies why do I need open SSH? I need open SSH because I need to do SCP what do I need to do SCP turns out I don't need 80% of open SSH and especially and so I would encourage you to do this as well switch programming languages so it's a you're running in Swift and then you call C library that's a loud right you're writing stuff in C sharp you can call C libraries you're writing stuff in Python you can call C libraries but then switch to the I'm not going to do that I'm going to use my own copy of it and in the case of Python you have Parameco so you can just copy the bits of Parameco that you want and I don't know that there are a lot of you know how much vulnerabilities people have found in Parameco because I'm going to hack the organization so I take your point crypto is hard don't start there it's you know it's for the advanced section only but you'll be able to satisfy yourself whether the rest of my thesis makes sense up through the crypto boundary and you know if you agree with me until that point then we can have a follow-up meeting in which we discuss how we cross the crypto divide is that fair? I thought Simon and Tali convinced but I'm going to compromise and say take away all your dependencies except the crypto ones and I'll consider that a win the same argument applies to network protocols to file formats you don't want to write a web application you don't want to write a web server at the same time those are very easy so those are very easy as it turns out and I've done WebSockets and I've done a bunch of stuff like that and in fact my next project I have to be CAD diagrams so I'm working on reading what it was like DCG so the CAD drawing files is kind of my next project but so what I will say is the rule here is the rule is you can use anything in your base platform so if I'm writing an iOS app then I can use whatever is built into iOS because that's free and it's there so that's not a dependency if I need to get some other library then no so if I'm Linux is a little tougher because it's so vague and formless but it's like if I take my standard distro out of the box didn't turn on any additional stuff can I do that same thing for Windows so the idea is pick your platform and then you can only use what's in that platform for your stuff different platforms will have different capabilities but most platforms have built-in HTTP support so you don't have to write HTTP support so it's not it's is there a platform for you? is there a platform? what's the subset of the BIANS that qualifies a platform for you? it's so I'm not a Debian guy I mean people because he figured a different point of view is always good so I'll leave that to the intersection of figuring out how you decide what Debian is interestingly enough I was looking for this thing about code size and stuff so the question on my mind was and you can Google for this but Google doesn't know the answer it asks in this manner which is what is the largest project in terms of lines of code right and the answer you know you can't do that but anyway you can go say how many lines of code is this much? how many codes does that project have? so Debian weighs in as the biggest open source or free software project at 85 million lines of code but I'm not sure again how they count that it might count all of the things that have been packaged so then you would be counting all the Python source code and all the Postgres source code so again I'm not sure how but what I am saying is to approach it in that spirit which is obviously if you're sitting there and you're going to write this thing and you need some date arithmetic algorithm in your Python code and it's not there and you're going to do a pip install or an app get your cheating right wasn't there in your platform at that time so in Python it's really easy if you have a dependency.txt or whatever it's called file get rid of that so in any platform there's kind of a cultural sensibility for what's in and what's out I'm getting flashed you only have 60 seconds so I'm going to have to say I don't think there's any way I can answer a question in 60 seconds I don't know if you've noticed but when I get a question I answer it and spot I am going to be out there for the rest of the day so if anybody wants to do more questions, answers, sparring debates, education etc I will deal with that that's why I'm here thank you so much for coming out great questions and I look forward to doing more. Thank you