 A lot of people forget what we're talking about. No, I don't want to. We'll look it up in zero. He'll show up. Probably don't be fired up. He'll just walk in five minutes late. Jazz club. The brothers thought they should make the pedal more interesting. There he is. There we go. Are we doing it? Yeah, I think this one is going to happen. No, there's nothing equivalent to that. Thanks for your press to invite me. You guys know what you're doing or not. You can talk. We're all fine. I don't know what I'm doing. This is my first post-it and I don't even know what I'm doing. I'm really jealous that Mike's bare. Does anybody else want to be bare? Yeah, I'm going to go get him. I'm going to get him. Yeah, yeah. I'm mad fast. What's that? Is that your friend? No, it's my beer. Oh, it's getting beer. Is it not working? Why don't we just pass it around? That's on your laptop. He should be working. Okay. He's got it. I think it's good. I'll just go back where it was. Okay, so we're going to end the day with a panel discussion of the speakers. We wanted to get, but ended up not being able to get. We'll go around the panel and have you all introduce yourself. Then start the end, Sam. I'm Sam Boyer. I am a software engineer at Stripe. I work on package management for the Go programming language, and I like package management very much. That's a problem. And I'm Philippe Ombredin. I write tools to detect the origin and license of code with open source and open source. And business-wise, I'm the city of a small startup which does the same, but also for professional services for companies. I'm Todd Gamblin. I'm a computer scientist at Lawrence Livermore National Web. I work on making parallel simulations go fast, and I also maintain a package manager called Spackle. I'm Michael Quaid. I'm the lead maintainer of Homebrew. And my day job was at GitHub. The reason why I actually wasn't able to get me for this was because I, on reflex, submitted this to the room I normally submit things to and then complained about why they'd not accepted my talk, which I'd submitted to the wrong room. You could have not accepted anywhere, no? I think the other room would have had to accept it or something like that. Yeah, you can accept your own talks across them. I think you're going to be talking about that. Okay, so we'll start off with a nice, light, easy question. Just a quick fire. Tabs or spaces? I work and go. I don't have a choice. And I'm happy about it, tabs. I work in Python. I don't have a choice. I do actually, but I love spaces. And four, please. Not too like Google or... Spaces. I work at Ruby, so I would prefer to be using tabs, but I have to use spaces today. What? Okay, we're all nicely warmed up. So we're all in agreement, basically. Half of us and half of us. Which would you say your favorite element or favorite feature from a package manager is not necessarily one that you've developed yourself? Would you like to steal or to see implemented in every other package manager? Are we going this way every time? If you like, if anyone has very strong feelings... Let's switch it up. Go from there and first this time. I don't know about features, but I think app gets a really great package manager. The UI isn't always incredible, but it's really fast and generally just does its job well. So I would like to... I sometimes dream about just rewriting homebrew. It's like a thin layer on top of app, yeah? I like good dependency resolution, so I guess I'd like to see that in all the other package managers. I think that's something I haven't implemented in my own yet, but we're working on it. I think I would like to use a single package manager and not have like 20 to deal with. Yeah, wouldn't that be nice? So, right now I can point to I just found out like three days ago that Dart just implemented unit propagation in their SAT solver. And apparently I haven't looked at it yet, but apparently it makes for much more followable error messages. And the reverse of that, which feature or attribute of package manager would you like, Z-die and a fire? I'll start. Yeah, so I have one. So there's one in SPAC actually that I wrote. So we actually... we have a package from some scientists who are very good at packaging, don't get me wrong, where they maintain a 40,000 line patch on one of their dependencies. And so we actually implemented the ability in SPAC to have patches on your dependencies. And SPAC will build you a special version of that library just for you. And so it actually gives it a separate hash that's based on the content of the patch. So you can have your own little sandboxed library. So I wish that we did not have to do this. So I hope that feature dies in the fire because people stop doing this. Let's just drill down on that. I know you have some opinions on patching. Yeah, I had a lot of other ideas, but then Todd's... that's the worst I've ever heard. It's like... it's like those dedicated injection stations where we're not... you know, they do this thing. We want to support them in the community. We want to bring them in, but we can't do it unless we allow them to do this thing that we don't like. And so we're bringing them in, and we hope that we can use this to find the packages that do it and tell them, stop that. I hate patches in general. So that's where I'm coming from. So does anyone here know or remember that Debbie in the open SSL patched the buckle? Some people. Some people covering their face. Yeah, and it's one of those things. It's not... no one is to blame for it. It was more an infrastructure architectural thing rather than any individual. So basically what happened with Debbie was they have, like a lot of package managers, they will patch things if they appear to be not working weirdly and then they will try and submit their patches upstream. There was an issue where they would run Valgrind on things like open SSL, and open SSL was reading from memory that wasn't allocated. And this is almost always a very bad idea. So they basically patched that out and submit the patch upstream. Never heard a response back on that, and turns out for a few years that this patch was patching out a source of entropy in open SSL, which I don't know how much you know or don't know about encryption, but basically that means that, like, the encryption was made much worse than it should have been for Key Generation. So basically any machine using Debian or Ubuntu had to regenerate all of their keys they were using for anything with open SSL because they were all predictable, effectively. So it was possible for other people knowing stuff about that machine, for example, the date, the time, the input devices, for example, to predict similar keys and then go forward and basically obliterate all the encryption on the machine. And this all happened because someone decided they knew better than the open SSL maintainers by how open SSL should work and then submit to the patch and then just applied that pattern definitely for years. So this was one of the things... Sorry, how did this happen? Yeah, no, I agree. To be clear, this is a mistake I would have made myself. If I was a Debian maintainer I'm not blaming that maintainer. What I blame is the process, not the individual. As I say, I have made similar mistakes like that myself. The best is that we have a lot of package managers who fell in love with patching things that they didn't necessarily understand the consequences of their patches. And as a result, you end up with software which doesn't work how it's meant to work. And that's why I think patching widespread is a bad idea. To be clear, again, I'm not blaming any individual. Maybe it's just symptomatic of the various upstream packages you submit a bug or whatever else in the other holiday for the rest of their lives. So if they feel you clearly don't patch that because you screw up all the stuff then presumably this opinion patch would not have lived so long. But in those cases, if people don't respond to your patch submissions, then you shouldn't be including that software at all. And if it's something crucial like OpenSSL, if they're not responding to your patch submissions, then that's a bigger problem. And yeah, so, sorry. Obviously, you got me in my soapbox. Nice segue into the kind of discussion about whether packages and package registries should be created or vetted or approved and where does the onus of responsibility and maintenance exist or where should it exist in the case of Sam and Go. It's much more extremely on the user as a responsible person. Non-optional, yeah. If you think that, I mean, within Google, that's entirely not even a problem, right? If you're using just an internal registration. So, yeah. So, I mean, for I don't think that the lack of a registry is a problem like accountability-wise for Go. Small things. I think there are much bigger problems that we have that arise from not having a registry. Incidentally, we're going to have a registry. That will happen. There's like, there's no question about it. There's just a question of getting to it. But, yeah, I mean, like, things that we can't do, for example, right now is any sort of there we go. Come on, come on. All right. All right. Cheers. Cheers. Sorry folks, all of you. So, there we go. All right. I think you forgot a few poops. All right. We'll have beers after it. It'll be great. Yeah, nice, nice, Boston cup of beer. So, yeah, no, the things that we can't do, for example, is we can't do like a yank of a version, which is a really valuable thing to be able to do. This version's bad. Don't pretend like it's listed by removing it, but instead mark it with some metadata. That's bad. That doesn't exist. We can't do that because we don't have anything central like that. We also can't apply literally any kind of filtering as to whether or not, like, I mean, you know, do you even have like valid go code in there or does it all just not compile at all? Like, we can't even do the basis level of filtering because everything just goes straight back to the original version control source repository. Or, yeah, for, with language package managers anyway, I don't think there's a lot of value in I'm fine with an open universe that has no, that has no limitations on who can actually push into it. I think that that's the sort of thing where you should filter outputs not inputs. I think, I agree with you, but I think on yours around, so say there's a bad go package or bad pipi package. And because there's a few bad apples, every users will have therefore to vets and review every bits of code they need to use ahead of time and they don't have any warning. So the work to actually create our vets, if there's no central visibility ends up being done over and over and over again. Take a practical example, a package without a license, right, where license is whether you're in a commercial setting or a free software setting is a getting item before being able to do anything with the code. If you don't have a license and there's nothing that happens to patch upstream, no information that there's no license available, every single users that's responsible will have to check. And that's going to happen one time, a thousand times, or ten thousand times until it's fixed. And that's where I think some curation or some visibility about the lack of curation is important because otherwise we just reinvent and redo the stuff over and over again. So can I clear about the question? Did you mean like you have to be, you know, granted special special powers in order to be able to publish or were you talking about like any level of... Whatever that means I guess, in the case of vetting or some way of essentially gatekeeping an approved set of packages. So maybe in central you need to get approval for a namespace before you can publish to that. Which means that you can't type a squat on Google or similar before Google gets there. Yeah. Once that is enabled then you can publish as much as you like. That potentially stops some issues but on the flip side trade off as with everything in tax management the trade off is that you have to go through Maven Central and talk to another human to be able to publish that thing. Yeah, yeah, no I would say I mean, my line is automated verification of code no anointing of humans. I'm with you there I think it's probably more trust and verify than probably be publishing at first and limit the flow. It's probably more putting arbitrary barriers if you systematically reject something for whatever factor. Now being able to alert a user that since shitty code this is vulnerable, it has no license nobody uses it I think it's valuable but then you do it after the fact and the user has eventually available the information rather than being stopped as an author to publish anything. For us it's a that's all that's before they can access the namespace and the namespace is based on domain name, right? The access What happens if the domain changes owner? Do they read that everything? The namespace is a terribly bad idea anyway They should go away. Any questions for any Java people in the room I guess? I can give you my opinion there I think the namespace in Meven are a terribly bad idea and should never have existed in the first place They should go away. I know the host I'm not sure but based on the process of approving I know five years ago there's certainly not such a check because it works in way that you open issue on some Jira of organization you can write some information about the US of what you want to package your domain name they will probably manually report and how long it takes to check the domain and the information you enter it and you're in and I never get any email something after that so I think there's no such a check Interesting I'm just going about it's still much better than in or any different big manager there are a lot of complaints about how Meven Central works and I think that left path and similar issues for these strict rules in Meven Central actually make sense Getting back to your point about tying namespace to a domain name that has a lot of issues obviously I mean what if just the domain falls out of registration and there's this implicit relationship that's working and I don't think in the case of Meven they've actually even ever enforced that seriously I know package in the comms name space which are not from son or were never from son and definitely not from Oracle Acer GNA is one example Java native application interface which is a kind of foreign function interface for Java excuse me it's a good library I think for Java we quietly sat here whilst loading it over the homebrew registry and deciding whether or not to thumbs up or down any package at any point do you have any opinions on this? I would love to hear Todd first yeah so we're similar to homebrew in this regard in that currently I mean it's back ships with a built-in package repository and it comes with the repo because we don't have a stable package API yet you know in our stage we don't we approve a lot of things because we're trying to ramp up participation and get more people contributing and it's hard enough to get HPC people to package anything and I think that we're just happy that they do I think that this question has come up in the context of hey we're going to try to use back to package all the stuff that the US exascale program is and then that's you know some sort of vetted package repository with their name on it and so you know at that point we're planning on having more aggressive build tests for packages you know I would hope we would do some kind of security testing although I don't know exactly what we can do in that area but if we did that then we would probably just separate that out as you know that's the vetted repo and you know that's what comes with the thing when you download it and if you want to have another ecosystem you can have that on the side and maybe we even support like a bleeding edge ecosystem that we help you merge things into we just don't call it stable or you know reliable so that's what I would say I think it depends on the phase of your project if your project gets big and you know the life of the project really depends on whether or not things are vetted and whether people can rely on it then I think you do need to start vending things if you're trying to grow then you know there's a process that you go through to get to that point yeah I think like homebrew has gone through that process as well I think the interesting thing is I guess you see even on the panel the difference between language and system package managers where like if what people are uploading to you is effectively what you are delivering to people as well like you say MPM or RubyGems you upload the source code effectively and then people download the source code and then it's built on there of local machine then that's fine when you start getting to the point where you're you pull the source code from elsewhere then you download it, you build something and then when you deliver it to users it's normally the artifact of that like say a binary package or whatever then things start to get a little bit more complex because then what we are giving to our users is not necessarily exactly what Upstream has given us and it depends on the compiler flags and the systems we build it on and stuff like that I think other than anything else we don't want people to be running arbitrary code on our CI machines and it's fine to do so, they're protected from that but like we don't just want to allow someone to upload a package with a billion lines of code which then takes down our CI boxes or whatever because it takes too long to build and so I think we've moved over time from the we'll accept just about anything model to having a curated core and then we used to have kind of more like semi curated like these are official like blessed other repositories but again that model hasn't really worked for us either because people see the homebrew name next to a repository and they think that's official and therefore everything should work just as well and we find it's kind of easier just bringing everything in that we want to into a single repository which we maintain a consistent standard on and then if people want to do their own thing then they can go off and do that elsewhere on GitHub I guess almost kind of go style but then that's under their name and there's no expectation that homebrew itself is to blame if that thing doesn't work whereas anything with like you know homebrew signs homebrew PHP, homebrew engine X that looks like it's an official homebrew project and therefore when it doesn't work and no one replies to your issue because the particular maintainers we delegated to in that repository aren't responsive then I think that reflects back on the whole project so it's yeah it's a tough balance I think okay so you all mentioned that there probably should be some form of human involved in the process Todd posed an interesting question to me earlier about the idea of potentially being able to automate all of package management is that even possible and if it is should we try to remove humans from the kind of the process or is it something that is like humans have to be involved in this so what are you saying is it is it possible to build software automatically sure will it do anything useful probably not much that's the difficulty if you think about packages as Lego or Mechano what we as software developers will end up doing is gluing these in a certain pattern together and that's still a skill and I sure so we try to automate probably a lot more aspects of building a package different ways than other package managers and so I'm the big fan of trying to expose enough information to do that that said like we're not emphasizing stability right now what we want to do is expose all the options and make it so that we can automate things and test enough of the configuration space that we could have a reasonable chance that a tweaked build that someone executes will build and run successfully so that they can tune easily so that you can potentially auto tune your packages I think that would be really really cool but that said there is an iterative process to even that where you have to work with the human to actually get the thing packaged in the first place and expose the parameters and I don't know if you can automate that maybe for some of the common build systems I mean you could probably learn that stuff but people sort of kind of stock there's all kinds of interesting things that happen in package managers that are out of the ordinary when we look at package manager registries and the development that goes into package management is to be clear where the source of funding is behind the work that goes into the software that connects all of those ecosystem together do you have any ideas of ways to make package management, development and maintenance more sustainable aside from venture capital I think that is one way around wait you said sustainable though sustainable no, venture capital so now the interesting question is there is really possibly two types of registries some that are under the direct explicit or implicit control of a for profit corporation and I could name for instance Maven with standard type or NPMGS for node in this domain some that are under the control of a community and typically a major foundation behind the community like the case of Python or Ruby the thing for instance look at Python we were two inches away to lose support entirely for any stable maintainers the lead maintainer lost his job and his company was helping make bad build to the basis so sustainability is a difficult thing the thing that's a problem is if you have for profit entities into the equation then the relation with the community is eventually a bit biased to say the least that's an interesting area that I'm going to point back at Mike and I've turned towards the relationship that github has with open source and especially where people use github as the database or the registry where potentially kind of running on goodwill as a marketing agent is that a long term option for package managers I don't know if it is a good term option for github or package managers that said I maintain a package manager that does that so github's principle in general has been we don't really care how you use github as long as you're not abusing it in such a way that it adversely affects other people then you start to get down to weird things like how do you structure your git repo and if you have directories with 50,000 files in them then that makes things very slow and if you have 50,000 directories and a nest of hierarchy with one file in them then that can actually be quite fast and that's okay so I think github I can't speak for github because they don't pay me to talk about things like that but in general it's more or less as long as you're not causing us problems it's fine I think that's an interesting one in terms of I guess we touched on Philippe with for profit and not where for profit companies are able to provide often these services which the community can rely on and I think that's generally actually a pretty good thing although they may end up with a biased relationship with that community then I think it still provides a rising tide of what community can kind of expand be provided so before github a lot of us were spitting up our own you know if you want to get hosting before github you're running your own server to provide that for you there was a repository in Czechoslovakia at the time yeah exactly so there was various that's right oh yeah essentially that's easy that's right yeah you're still always relying on someone else's will or money to pay for that and I guess I would rather see the money that's being spent on this stuff is coming from some organization which is still able to make a profit then the alternative which is generally that that money is being paid for out of some open source maintainers pocket or or even the donations of a community I mean for me I think the long term viability would be solved by the very large companies of which I would say github is not actually one but the very large type companies that rely very heavily on a lot of these tools need to start paying back I can say that I've reached out in homebrew's case and I'm not going to name them to several large tech companies that swear blind that they don't use homebrew very much at all except there's a hundred thousand dollars every day no but exactly but we have our analytics which point to have your IP blocked dude like why yeah exactly so they will deny they'll swear blind that they don't use that this stuff really but then organizationally not think that they do but it just so happens that 90% of their engineers do or whatever and that's that's fine but I think we need to figure out a way longer term the open source that is very wisely used by people to bluntly by people doing their jobs to make money needs to not be built on the back of volunteers in their evenings and weekends because it doesn't scale package managers seem to be one of the worst affected by the free rider problem it's alright so I was saying me go ahead I'll go last I was going to say yes I feel the free rider problem what is the free rider problem I don't subscribe to this being a problem okay the free rider thing it's like an official problem in economics you call it a problem talking about policy of the commons tragedy of the commons so there's I'm actually and I'm particularly curious so for the last four or five months I said before that like a registry is coming to go and it is I've been working with a few people including folks at JFrog who do a lot of homebrew binary hosting but so at least at the language package management level right like the more I sit right now it feels kind of clean and I feel like I can describe a system where people are well incentivized for at least part of the set of expenses right like the general problem of package management being underappreciated and despite the fact that I get literally butterflies on it nobody wants to pay for it that's another thing but registry hosting like you know there's a subset of costs that we can focus on so I've been working with folks from JFrog I'm trying to articulate what a registry for go should look like and the expectation coming out of this and this is actually something that I'm I'm hoping we'll have like a bunch of stuff to put out in public for discussion in the next month and a half or so it's complicated but we'll see but I see what seems like a happy path right where if we can define a specification for what a registry looks like then that registry is the same whether it is public or private the distinction between a public and private registry should not be at the level of the API in a way that you could assume information from it that doesn't make any sense so if there is a certain amount of labor that goes into like let's define the standard let's implement that let's sort of have that let's maintain the standard over time but once you have that it seems feasible and in this case it's working out where JFrog has suggested that it would be possible that like if we have a public registry that they might just host everything there for us right and they do most of it well they hosted Conan right they took on Conan and absorbed it into JFrog so they'd have a viable C++ package manager and that's basically the point exactly like they're companies which are well incentivized because when they work on providing the API that is consumed by the public they have all of the infrastructure that they need in order to provide the same thing as a private service that they charge for two companies it's you know configuration flippies that's it so that specific part of this actually seems to work fairly well like we shouldn't have to worry about bandwidth costs we shouldn't have to worry about storage costs all those things that come with actually you know the physical process of hosting this there's still labor costs that come from the logic and management of the thing over time but it feels to me like there is a reasonable economic model at least for the hosting part of it at least because this one company exists I mean one company is not a general argument but like yeah it seems reasonable to me that we could solve that part of it so in your question that was freeriding on package managers or freeriding on package on manage package resources or freeriding on the packaging of packages I think it just means that how do you make sure that the project remains sustainable and well funded and that everyone isn't just using it for free when you know and getting value out of it without bothering to give back and maintain the core of the project right so I mean it would be sad if something like that died no no I agree but so in general for free and open source software you absolutely must have a lot of freeriders otherwise you just don't exist freeriders are the justifications for contributors to be willing to contribute because there's a lot of freeriders to cater for at least that's my take but you don't want only freeriders of course I'll throw this out here's another I have a slightly different funding situation from the other folks here although I mean we're not we're not a large corporation in any sense just have a budget of how many billion dollars but that's not for my project so let's back up a second so I work for the department of energy and one of the labs and it happens to be Lawrence Livermore yes their budget is 1. something billion a year but that's dedicated to maintaining the nuclear stockpile and so not a package manager I'll get to that and the DOE has lots of alternative energy and all sorts of other missions that they do and it all hinges on supercomputing and we have this big national exascale project right now that the six big labs with supercomputing centers are participating in and so in my experience if you want to make something sustainable then you need to make it critical for someone's mission so that they will pay for it and some people maybe that's a few people but in our case we've been able to argue for SPAC just based on the adoption that it's got and so like I have that plot in my presentation that says here's the lines of code in packages over time and here's where they came from we're able to show ultimately our mission is to benefit the U.S. taxpayers and if we can show that scientists are getting more work done efficiently because of SPAC and so if we can show charts like this that say look this is used at like all six national labs or all six of the ones that are in the exascale program and that you know the scientific software stack is being built with it then we can make arguments like we should use SPAC to test that software stack as part of like the exascale project and so on and so like basically like we from the start I have driven to integrated into things that are important in the organization like at Livermore it's our major code teams is it benefiting them at the DOE level is it benefiting the exascale project and the more of that you can do then the more funding you can get for things and I think that's paid off because I mean we are planning to do a big release plan for SPAC where we would do CI we would have a release in a test engineer and we'd have some funding at the different facilities to do package integration for the scientists there so I mean and then that can sustain the project and the contributions that we get and there are a lot of free riders that we're getting more out than we put in like there are packages that are users at Livermore go to build that they can build because some random person on the internet put it in SPAC and that's a big deal people actually appreciate that so we've been able to make that case I think that's harder when you don't have like a large organization overarching the thing but I do think this is one area where it's very supportive and stuff like this if you can show a direct mind to benefit to the programs and I think that's the thing I guess as we talked about free riders I agree that there has to be a certain number that's essential and I don't think anyone working on package management or any open source really begrudges an 18, 20 year old student who doesn't have a lot of money except for maybe a couple of beers at the weekend spend on software like I don't want to be receiving donations from those people the sad thing is those are the type of people who are giving donations and the objection I have is when you have literally billion dollar corporations who are not being prepared to give like a dime to open source projects that save them probably not to exaggerate millions of hours a year of their engineers time and I think for me that's the wider problem of how do we figure out how to companies that are benefitting disproportionately from this stuff how do we convince them or make it easier for them to donate to these projects where when you look at something like a Humbrew Kickstarter or a Humbrew Patreon most of the people who are donating there frankly I'm very glad they are but frankly they're the last people who should be because they're often people who aren't they're not swimming in money and they're not getting as much benefit from Humbrew as other people are but yet they're the ones who want to fund their infrastructure so how do we figure out how we can make this and I think this applies to open source in general how it doesn't rely on the generosity of individuals and instead becomes something that becomes the generosity perhaps of wider society and government and corporations it's actually not a problem with open source it's a general problem I have a niece I'm an old fart a niece that works for the Red Cross to solicit donations and something she hates is going in the more posh neighborhoods because they give squat and when she go in the less affluent neighborhoods and poorer neighborhoods she receives tons of stuff and so I think that's a fact there's probably not much that can be done about here but I don't think really it's a super problem unless you reach the point where the project no longer can sustain itself at all and then you basically have the issue of what happened to open SSL and they got eventually funding for the work they do and there's a few other projects that were in that situation where there were critical pieces of infrastructure that nobody knew or considered as being important because it was taken for granted until until you realize actually there was really nothing to say but I think it's important to be aware of that right if you wouldn't have seen that happen if the open SSL developers for instance their case were communicating about that and trying to be upfront or reaching out and maybe they were I'm not privy to anything there I think that's part of the responsibility of an open source software manager is to reach out to make sure you're known and appreciated if anything to attract community and if anything to be able to sustain yourself if you as an author disappears why didn't you have blackout days for certain repos and say haha so the thing is that how do you know that you have users if you're a bona fide open source project and you don't have a central repository the only time you know you have a user is when there's a bug I remember talking with someone a long time ago he was building ERP software open source software he says he was selling support services and he was telling me we've never had a better business when we were doing shitty releases because all of a sudden users realize that everything was not for free and then it would be a good idea to play for some support one of the best ways to find the most interested parties in your software is to release something and they will pop up pretty quickly just want to point out a word that you both used which was infrastructure and infrastructure in the package management world is much different to say open SSL open SSL is an artifact that people pick up and use and deploy as individual libraries whereas package management is literally a service that runs in the same way that water and electricity runs but there seems to be very little respect in the especially the business world that actually those registries are like electricity to their software projects so this is the point that this leads to a point that this is be careful about the way that I make this point so I would not analogize it to to utilities necessarily I think the more useful analogy is to work that's done by humans that's frequently overlooked so let's talk about you know the fact that the meetings that happen between I don't know high level lawyers or whomever actually have to get scheduled and organized by some group of people right and turns out because we're computer people we know that scheduling is a hard problem like actual capital H hard problem we have things called schedulers that do it because it's a hard fucking problem and anyone who's actually looked at a calendar to try to figure out how to get 12 different people with ridiculously packed schedules together knows that it's a really hard problem but it's not like we're crediting the people who are doing the work and they're doing meetings with the success of the outcome of the meeting literally ever they're never even mentioned they're not a part of it at all they're just a part of the thing that has to happen in order to get to the interesting work like the first organizer for instance yeah organizers of conferences people who yeah work as as perceptionists I mean there's a whole class of invisible labor and I think that and you know there's there's a mirror that I that I mentioned in my talk right which is that nobody ever wants package management problems you don't wake up in the morning thinking you know what I'm going to do I'm going to solve that conflict that's what I'm going to do that's going to be my morning it's going to be great I'm going to feel great I have a great lunch after that that's not how things go I do that but like you know you're working on something else and then package management comes up like it's it's the incidental thing right so there is this this this connects with the idea of gendered work and then even gets into emotional labor like there's a whole giant pile of of understanding of when certain classes of work get ignored so one of the reasons why I was kind of discussing this after my my talk earlier one of the reasons that I think it is important to try to surface package management as a problem domain that is analogous to compilers I was comparing compilers it's for many reasons but like I think that's important and I have been trying to figure out the ways like get academics interested and stuff like that is because we have to come out of the shadows by having some sort of like oh this is actually like interesting to people who work on things this is not just a prerequisite have you thought about publishing papers yes I mean having done that like I would that is a way to do it that is when we got our contributions up and there are papers in Papo right now which are I've been pointed towards to say like hey this is a you know a place to belong from there papers from Lisa yeah lots of things there's venues for it but the point is that we have been sort of what feels like a rounding error or an after effect for a long time in the space of actually building software because we're just the tool that gets you to the thing that you care about we're never the thing that you actually care about unless you're doing the work so to be fair I think that's for the academic side of things I think there's a whole lot of really interesting problems in package management that need to be formalized and written down and there's not that much of that out there so that's one way to get academics excited about it but I don't think that solves your sustainability problem no that was one little thing I have a quick question about that because as an academic and as a maintainable package manager I know right I know right we've tried like in our team like we have other academics we try to publish and we got rejections that says like this is a very nice paper but this is not the venue and the reviewers say unfortunately I don't know where else to suggest that you guys send the paper package manager we're organizing a workshop at Supercomputing to publish it at FOSDEM yeah push it to ArcSafe go out of the beaten pass the over beaten pass put a talk at FOSDEM or in the tech conference publish paper at the same time and that creates some awareness and maybe you will not get the exact peer recognition that you crave for but it will still probably be very useful it's better than a rejected paper in any case peer recognition isn't paying bills though yeah that's true for academics that doesn't work actually like I've been thinking for a while about as you said yourself about ways that potentially you could have a perhaps a greyout instead of a blackout yeah exactly like to demonstrate that you know not but again when I get very grumpy about hungry stuff sometimes I debate about just turning it off for a day and then letting people see and then be like ok well maybe you can pay for this then but a way I could think of doing that perhaps slightly more diplomatically would be a little message that pops up if you're on a particular large corporations IP range for example maybe with Jimmy Wells' face exactly have you thought about donating to Hovering you don't get access to binary packages so that means that you still get software that works but it ends up wasting a bunch of your time generating essentially the same software that you could have downloaded we won't give that stuff that you can download to you because again it's interesting that J.Froggin was mentioned earlier so Bintray is the main Humbrew package host and they are providing essentially for free like terabytes of downloads a month to Humbrew users and I think and I'm sure they don't begrudge doing that and I'm sure they particularly don't begrudge doing that to students I wouldn't be surprised if people in Bintray slightly begrudge doing that to corporations that have a market cap 100,000 times the size of them who are effectively again freeloading off the charity organizations and lastly sat across almost every package manager and lastly at donating so many gigabytes of bandwidth every day to almost every large package manager is going through them without pain they donate all of that bandwidth for free if they decided not to do that or their VC funding runs out and they actually have to make a profit they turn all of those off and Python had this oh no read the docs had this with essentially the host saying and I think it was accidental but like we're not going to provide free hosting to you anymore they would have been straight out of business and the whole service would have been shut down so isn't there a problem to have centralized minority registry a problem that creates this kind of situations yeah so you're focusing the attention if you're focusing on one IP, one domain one host sounds just like they're smiting right there we don't have that because that's a problem Go doesn't have except we do a single point of failure come on, seriously a composer tries to do the same for PHP and doesn't have a central registry per se it's more like a catalog but it's not really a registry but it just refers right back to Github that actually goes to anything themselves so is the problem Github? it's not a problem so far it could become a problem it's not a problem with single points of failure but the choice here is not between single point of failure and perfect distribute everything on IPFS responsibility evenly distributed across the world the choice is between single point of failure and that's the choice like realistically and there are a lot of windmills that I have tilted out in my life but this is not one that I choose to tilt at anymore you find a company like Fastly yes like they're probably not going to turn off their support anytime soon there are enough forces at work there that it will probably at least keep them socially at bay if they were to turn off support for read the docs if Fastly goes under there are other CDNs like you know they represent a significant portion of handling traffic on the internet but I'm not saying it's great I'm just saying in the set of options that we have with focusing on other things rather than reducing SPOF there I think you got to get a set of core people focused on making sure that they have a next source of funding if something goes wrong but I mean I don't think they have to as long as the governance is sustainable if there's one person maintaining the project and they get burnt out I think that's a much more severe concern than that you have all the resources that you need because I think if you have a group of people who really care about the project they're going to continue to push and find avenues for funding it okay so we have five minutes we just know that central registry does not equal one hosting, one domain or one eye gathers it works very well in I think most of all distributions that have so-called mirrors there's still something like registry some file that describes that registry is available and it's replicated to many servers around the world so there's a question at the back yeah I was just I wonder about so the relationship with something like JFrog where if Go package registry is going to rely on JFrog the popularity would go as it increases, JFrog is going to have increased revenue from enterprise deployments of this package registry but if that revenue doesn't translate back to the Go project the popularity also means that the number of issues and other traffic that you have to deal with from the Go project is also increasing that seems like a fundamental imbalance that feels like that has to translate back somehow because that's the greatest one-way street that I see we've seen that a lot in the MPM world like the MPM client is open source we cannot keep up with the level of activity the amount of bugs reported is nowhere near and MPM has probably is one of the registries with the most resources behind it to be able to solve problems and they can't employ enough people to keep up the amount of users despite this ridiculous growth where does it end or should we have more smaller things that are rather than massive registries trying to break those things out is there a way of avoiding that spiralling cycle of of increased growth I think part of that is that we've I think we've got bad in the last five or ten years at mixing support requests with issues so certainly when I go somewhere in KDE ten years ago and that's where I cut my teeth in open source and there was no expectation that if you as a user couldn't work out how to do something in K-mail that it was a reasonable thing for you to do to file a bug on the KDE bugzilla and then expect the K-mail maintainer to tell you how to use K-mail whereas the wider open-source ecosystem now it does appear that most projects have begrudgingly accepted that if someone can't work out how to use your stuff that's on you to like walk them through the process I've happily accepted that not begrudgingly and there's people who like that to be fair that's fine but that really doesn't scale there's a lot of open source projects I see people being crushed by the weight of their own benevolence frankly where one of the things with homebrew that I guess I've realised eventually it's not effective for me to walk someone through who is literally using the terminal for the first time how to type their password into sudo because it doesn't show the stars that they're used to in a GUI literally this happens monthly but that's not a good use of my time because if I spend an hour helping that person that's an hour I'm not fixing bugs that affect 10,000 or 100,000 other people so I think that's the tricky balance that we're having to get to as well I think personally a lot of projects over commit in terms of they expect they provide an expectation to their users that they're going to help them with any problem they have rather than expectations to the users that if you can provide a reproducible test case that I can apply on my machine and reproduce as a bug I will commit to trying to fix that at some point like that to me is a more realistic expectation it stops people burning out but this isn't a popular opinion it's popular, it makes a lot of sense now it's probably just a matter of which stage package manager tool or not in terms of maturity you are at the beginning it probably makes sense to say I'll do anything for you because I want you to use my tool as you grow you have two cases you were successful to growing also not only a base of users but a few contributors and you should delegate these more mundane questions to new and aspiring contributors because otherwise you're going to get crushed and burned out pretty quickly I feel bad which is not a good thing one of the best ways to do that is to just leave it I have found that actually I mean inadvertently found kind of, I had a baby and I was like what's going to happen I'm not there to respond to issues people stepped in and said we're going to take over and help out with these issues and I think focusing on growing your community and focusing on your contributors like the Humber guys do is the right way to go because then you will have people who can kind of fill in for things like that and if some issues get left which they will then at some point there's not much you can do about that so it might be interesting for GitHub to have some kind of metric that says it doesn't look at the amount of open issues as a bad thing it's a metric of how much support does this project need how much are they able to meet demand for these services okay so we're again at the end just to run around the panel quickly and get an idea of where they think or would like the future of package management to go it doesn't have to include the sustainability discussion but just as a kind of a nice closing note, something slightly more positive maybe I have my answer I really want to define some sort of four language package managers doesn't have to be a universal tool but I want universal standards for describing what the actual contents are in a way that we can emit from either package managers or from running programs so that we can teach containers to actually read that information and container runtimes can report the actual full stack of software that they are running you can construct larger systems which are able to introspect containers to tell you the entire set of all of the versions of all the things that you have for all of your containers and all of your infrastructure because Google actually has something more or less like that and it's really great and this entire cloud native thing that we're doing right now is garbage pants as long as our containers are black boxes of what's running here I don't know look at the docker file that's terrible it's not okay but there's already a bunch of really interesting stuff around this and that's something that would have to be a sort of cross-language package manager effort to make a standard on that but I think we can do it so he stole my thunder basically Pearl's a part of that it would be yeah I mean yeah so having a common manifest format eventually going as far as having a package manager construction kit such that when there's a new language that pops up and that's great there's a new language that pops up they don't reinvent the wheel all over again everybody wants to write its package manager in its own language that kind of makes sense coming with a few convention standards approaches such that effectively you have manifest that makes sense then their data attributes schema align more or less the way they resolve dependencies aligns more or less it would go a very very long way so yeah I think I'm on the same page I would like something that you will have nothing to say okay I want it for a different reason though you want to introspect containers I want to introspect the system package manager and get enough information out of it to know what stuff is installed there that I can actually depend on because it seems like honestly that's what people want they like homebrew and you know they maintain things for macOS and they can assume that the macOS things are there whereas we're trying to run cross-platform and so in our model we have to abstract all the system dependencies and you have to register them explicitly if you want to depend on them I want enough metadata to make it reliable to build against them and then enough metadata to work with another package manager at the language level so for example I don't want to re-implement NPM I don't want to have anything to do with the JavaScript ecosystem in terms of managing its packages that is already done people know how to do that but I would like to fetch them archive them, install them put them in other environments and be able to work with them in like a system context and currently there isn't I don't see a good way to do that and the same for Java, for Composer, for VNL and I've written parsers like dandru and that's freaking stupid we've got multiple package managers but we've got multiple parsers of those package managers and a clean way to override I guess I would say so I want to pip install most things for Python if they're pure Python, fine but if it's NumPy, I really want to control libraries I want to optimize them so I want to be able to plug into that I don't know what that looks like but there's a variation between the different batch managers, that would be good so one part much to say more collaboration between package managers language ones, system ones all that type of thing I think we end up doing a lot of work in each of the package managers which we could share a lot more than we do and the other thing is being more financial resources for package managers in general nice can I add something? all operating systems except Linux that would make the life much easier that would make my life much easier that would make my life much easier if all the processors except for Haswell and then we'd be in a great shape all the GPUs except for one we could go around so I just want to thank all the panelists today and all the speakers we've had it's been amazing to have the first package manager room here hopefully we'll come back next year maybe with a slightly larger room hopefully this spurs on a lot of conversation around working together trying to standardise on some language even if that doesn't mean any more than just a shared knowledge base of all of the bare traps that you can step in whilst building a package manager would be a really good way of ensuring that we continue to build upwards rather than just keep building around each other Ben do you mind coming here for us again maybe if everybody can give a round of applause to the organisers Ben Andrew and I think that's everything for today thanks very much