[00:00.000 --> 00:15.720] Hi, everyone, and so, yes, Brian introduced me, I'm Teofan, I'm, so I'm a member of the [00:15.720 --> 00:20.520] NYX West Foundation Board, but I'm not going to talk about that today, because I'm also [00:20.520 --> 00:25.440] a NYX maintainer, I have been a NYX maintainer for the last few months, and I'm going to [00:25.440 --> 00:31.120] talk about the NYX package manager team, officially called the NYX team, but it's very confusing, [00:31.120 --> 00:36.760] so I won't call it like that, at least not in the first slide, which is a team that [00:36.760 --> 00:43.240] has spawned a few months ago to actually expand a bit on the maintenance of NYX. [00:43.240 --> 00:52.720] The reason why we created this team is that NYX, in some ways, had a bad reputation, both [00:52.720 --> 00:58.880] for contributors and for users, with this idea that the maintenance of NYX didn't care [00:58.880 --> 01:05.880] about contributors and users, which is not great for an, well, it's not great for a product [01:05.880 --> 01:13.500] and it's not great for an open source product, so to be fair, that's not true, a slightly [01:13.500 --> 01:18.800] less wrong amended version would be that the single NYX maintainer doesn't have the [01:18.800 --> 01:24.720] bandwidth to care about all that, because it's one guy hacking on a fairly big project [01:24.720 --> 01:30.000] for a bit of history, if you don't know NYX originally, that was a PhD project that Elko [01:30.000 --> 01:40.920] Dostra started, and then it has grown up progressively, the community has expanded, but until recently [01:40.920 --> 01:47.360] that was still only maintained by Elko Dostra as one person, which was definitely not enough [01:47.360 --> 01:56.040] for something of that size, but regardless of the fact that it's not someone not caring [01:56.040 --> 02:05.240] about anything, it's really more of an organizational problem, well, that's not great for a number [02:05.240 --> 02:12.360] of reasons, so as I said, contributors didn't really feel like they were as appreciated [02:12.360 --> 02:20.560] as they should have been, a lot of pull requests stayed unanswered for a long time or forever, [02:20.560 --> 02:27.680] even when they were answered, there was no guarantee that you could get an actual yes [02:27.680 --> 02:33.760] or no answer to is this pull request something that's going to be met eventually, and there [02:33.760 --> 02:40.080] was also no way for contributors to know before the fact whether what they were doing could [02:40.080 --> 02:46.320] fit the NYX style guide, because there was one, there still is one, but only one person [02:46.320 --> 02:53.280] knew it, and so as a contributor that was really, it was really tough to contribute [02:53.280 --> 03:03.080] to NYX because of all these kind of little things, and another problem which is more [03:03.080 --> 03:13.360] something for the users is that the release process of NYX was a bit chaotic, so the 2.3 [03:13.360 --> 03:22.040] release of NYX was somewhere around 2018, anyway, don't remember the exact date, but [03:22.040 --> 03:28.840] then NYX went for two years without a release, and when the 2.4 release came, I just made [03:28.840 --> 03:34.880] some quick starts, and I'm going to show up the interesting numbers, so NYX was 55,000 [03:34.880 --> 03:41.000] lines of C++ at that time, well, only counting the implementation files, and the diff between [03:41.000 --> 03:48.200] the 2.3 and 2.4 release was 32 new lines, or lines changed, so essentially half of NYX [03:48.200 --> 03:54.840] had been rewritten between the two releases, and as you can guess, that came with a number [03:54.840 --> 04:01.640] of breakages, honestly very few breakages given the size of the diff, but still way enough [04:01.640 --> 04:09.600] to annoy users, a lot of, regardless of the breakages, new features had been introduced, [04:09.600 --> 04:16.000] but not necessarily properly documented, or experimental features had been added and were [04:16.000 --> 04:21.640] like officially experimental, but that was not properly communicated, so people started [04:21.640 --> 04:27.960] relying on them as if they were actually stuff that you could use for production, and then [04:27.960 --> 04:35.640] they got changed, because they were just experimental and people got angry about that, I mean, rightfully [04:35.640 --> 04:40.240] for them point of view, unrightfully from the point of view of the maintenance, for which [04:40.240 --> 04:45.680] these were experimental, you should just not rely on them, but anyway, that led to a lot [04:45.680 --> 04:51.800] of frustration, and that has been going on for a long time, I think we could say that [04:51.800 --> 05:02.560] NYX has started being really a big enough project since the early 2010s, and it has [05:02.560 --> 05:11.880] kept growing ever since, so the frustration has kept growing with that, so in 2018 a group [05:11.880 --> 05:16.760] of people just sat together and decided that this just couldn't keep going, and so they [05:16.760 --> 05:24.360] decided to create the NYX core team, whose responsibility was exactly this, like improve [05:24.360 --> 05:28.880] the maintenance of NYX, make it clear what design decisions are, where the project is [05:28.880 --> 05:35.240] going, what contributors can expect from them, and what we expect from contributions, so [05:35.240 --> 05:45.800] that we could smoothen all that, so this core team was a great idea, but at least to me [05:45.800 --> 05:50.680] at that time, I wasn't that much involved in NYX at that time, I was only a user and [05:50.680 --> 05:56.760] very casual contributor, the main contribution for the NYX core team that I saw was one [05:56.760 --> 06:03.080] year later another announcement that the core team was disbanded because it hadn't done [06:03.080 --> 06:12.320] anything meaningful in that year, so yeah, that was unfortunately a bit of a failure. [06:12.320 --> 06:24.240] Now, well, then in the meantime I came to contribute more and more to NYX, it also happened [06:24.240 --> 06:30.440] that Elko and I got colleagues for some time, which really helps smoothen things a lot for [06:30.440 --> 06:35.400] my contributions because I could just ping him and say, hey, Elko, I have this for request, [06:35.400 --> 06:42.720] can you please review it, but that was really helpful, but unfortunately, well, maybe fortunately [06:42.720 --> 06:49.160] I guess that depends, but not everyone got to be Elko's colleagues, so that model couldn't [06:49.160 --> 06:58.960] really scale, and yeah, at some point we thought, well, we need to do something and maybe try [06:58.960 --> 07:05.200] again with that NYX core team, well, didn't manage to do, but then the big question is, [07:05.200 --> 07:09.840] well, how can we succeed if that core team failed? [07:09.840 --> 07:14.840] And like for the record, that team, if you look at the co-authors here, these were the [07:14.840 --> 07:20.320] biggest members of the NYX community at that time, that was not just a group of random people [07:20.320 --> 07:26.280] showing up and saying, hey, we want to maintain NYX, that was really a big community effort. [07:26.280 --> 07:34.240] So how could we make something that works, and why maybe could we make it work now? [07:34.240 --> 07:37.800] So I'll maybe expand a bit later on the how. [07:37.800 --> 07:43.400] The first question is, well, the first thing is that the circumstances were actually very [07:43.400 --> 07:46.920] different. [07:46.920 --> 07:53.440] If you look, so I dig a bit in the GitHub history stats, this is very blurry, but that's [07:53.440 --> 07:57.960] where you won't be tempted to read all the numbers, and you will just show the big shape [07:57.960 --> 07:58.960] of the graph. [07:58.960 --> 08:05.080] So these are the main commuters between 2003 and 2020. [08:05.080 --> 08:08.560] So that graph represents Elko's contributions. [08:08.560 --> 08:14.560] And these very, very, very, very tiny graphs that, yeah, I can see that one. [08:14.560 --> 08:18.360] It's not smaller than the pixels on the screen, but barely. [08:18.360 --> 08:21.520] So these are the other main contributors. [08:21.520 --> 08:27.960] So as you can see, well, that's really a one-person project with some contributors. [08:27.960 --> 08:32.880] If we look between 2021 and 2023, and I'm probably getting out of the camera field, [08:32.880 --> 08:38.000] so I'm going to stay where I am, well, you can see that, well, Elko is still the main [08:38.000 --> 08:39.000] contributor. [08:39.000 --> 08:40.000] That's no question about that. [08:40.000 --> 08:44.240] But then things are much more well-distributed after that. [08:44.240 --> 08:50.160] So that means that there's actually people who potentially are already investing enough [08:50.160 --> 08:55.240] time in Nix and could really take on a mentorship. [08:55.240 --> 09:04.520] And another key ingredient that also probably was missing at the time is that between 2018 [09:04.520 --> 09:11.840] and today, well, the Nix community has kept growing, and we have more and more industrial [09:11.840 --> 09:17.720] players in that community and more and more people who are paid to work on Nix. [09:17.720 --> 09:26.000] Like, well, Elko has the chance of always having been paid to work on Nix more or less, [09:26.000 --> 09:30.640] first as a PhD student, then getting hired by a company which gave him a lot of time [09:30.640 --> 09:33.400] to hack on it, then another and so on. [09:33.400 --> 09:39.480] But for a long time, he was mostly the only one, at least for Nix itself. [09:39.480 --> 09:46.080] But yeah, now things are changing, we're kind of growing up, we're a real community of people [09:46.080 --> 09:52.520] actually handling money and having people who have time to do this kind of boring and [09:52.520 --> 09:58.440] pay-full things or reviewing poor requests of code that someone else wrote, and obviously [09:58.440 --> 10:05.440] I didn't write it myself, so it's not good and I don't want to read it. [10:05.440 --> 10:06.760] But now we can leverage that. [10:06.760 --> 10:09.640] And so that's what we did. [10:09.640 --> 10:16.040] So we gathered a group of people, we sat together with Elko and the other people who [10:16.040 --> 10:21.720] would be one of our team members of that team. [10:21.720 --> 10:25.640] Everyone agreed that this was a great idea, we had a lot of disagreements on the tiny details [10:25.640 --> 10:29.800] because obviously that's how things go. [10:29.800 --> 10:35.480] But eventually we found that team, we announced it officially saying, hey, yeah, everyone [10:35.480 --> 10:40.240] agrees that there's problems, so we're just going to create a team to try and solve these [10:40.240 --> 10:42.680] problems. [10:42.680 --> 10:50.200] We set a simple but ambitious goal for the team, which was to basically take ownership [10:50.200 --> 11:00.320] of that Nix source code and lead it to better, to higher standards, both for contributors [11:00.320 --> 11:04.960] and for the end users, so that contributors could know that their contributions would [11:04.960 --> 11:10.160] be taken into account or know that they wouldn't in case these weren't things that we thought [11:10.160 --> 11:13.120] should lend into Nix, at least they should have clarity. [11:13.120 --> 11:18.960] And the users should know that Nix was something that they could rely on, that was robust, [11:18.960 --> 11:25.520] that fixes were met in time, that they had clear expectations and the support they could [11:25.520 --> 11:28.120] get. [11:28.120 --> 11:38.960] And because Nix starts to be reasonably big, we also thought that a single team of four [11:38.960 --> 11:45.600] or five people, well, that's already better than a team of one person, but that's still [11:45.600 --> 11:51.160] not enough really to manage the size of the Nix code base. [11:51.160 --> 11:57.560] Not so much the size, the code base is not that big, but the vitality and the amount [11:57.560 --> 12:00.400] of requests and issues that come in. [12:00.400 --> 12:05.400] So we decided that the first mean by which we would want to take ownership of that code [12:05.400 --> 12:14.560] was to actually enable more maintainers and contributors by writing some clear contributing [12:14.560 --> 12:20.840] guides so that people knew what to expect, by trying and grow more maintainers out of [12:20.840 --> 12:27.280] the existing contributors' base so that we would not be a bottleneck for someone having [12:27.280 --> 12:31.440] his pull request answered. [12:31.440 --> 12:43.960] And as part of that stewardship also, oh, I forgot a bit of history. [12:43.960 --> 12:50.680] So this was the main step towards that, but actually someone too decided to buy the ballot [12:50.680 --> 12:54.920] on another topic some month earlier. [12:54.920 --> 13:00.520] And yeah, same thing, people sat down together and decided, well, the Nix release process [13:00.520 --> 13:03.520] is not great, we need to improve that. [13:03.520 --> 13:10.160] Well, let's just have a fixed schedule, one release every six weeks, that's arbitrary. [13:10.160 --> 13:14.720] Probably half of this rule would say, well, this is a bad way of doing releases, you could [13:14.720 --> 13:19.880] just send another half would say, well, this is a bad way of doing things, just leave [13:19.880 --> 13:24.480] that head and the other half might agree. [13:24.480 --> 13:28.520] But anyway, everyone agreed that having that was better than nothing. [13:28.520 --> 13:32.000] Oh, and I'm talking too much. [13:32.000 --> 13:37.040] But then this release schedule also was something that was still in Elko's hands. [13:37.040 --> 13:41.840] And that, like, doing a release is not a big deal, but you have to think about it. [13:41.840 --> 13:48.240] And if you're the only one whose task every six weeks to do that, well, certainly, please [13:48.240 --> 13:52.720] don't go on vacation at the date of the release, because otherwise you're going to annoy everything. [13:52.720 --> 13:55.920] And please don't forget about it, because then you have, you're going to have 20 people [13:55.920 --> 13:58.640] yelling at you because you're three days late. [13:58.640 --> 14:08.720] So that team was also a way to share a bit this responsibility. [14:08.720 --> 14:16.040] And well, the big question then is, did we succeed? [14:16.040 --> 14:17.880] I hope so. [14:17.880 --> 14:22.040] I really, really hope so. [14:22.040 --> 14:29.400] So I don't think I gave you the date already, but we started all that last September, which [14:29.400 --> 14:32.400] means that we are six months in. [14:32.400 --> 14:36.640] And six months in, it's still a bit tough to see. [14:36.640 --> 14:42.160] The main indicator I have to think that's probably we've succeeded is that we've turned [14:42.160 --> 14:48.840] the NIC's commit tree into something that starts to look like a plausible metromap, [14:48.840 --> 14:55.000] which is always a good thing when you're maintaining an open source project. [14:55.000 --> 15:01.800] And in addition to that, for some less tangible factors, I think that the team is going reasonably [15:01.800 --> 15:11.760] well and NICs is starting to move forward at a more sustainable and pre-visible pace, [15:11.760 --> 15:15.760] which makes me very, very hopeful for the future. [15:15.760 --> 15:23.400] And just adding two minutes to expand a bit on that because this NICs team is not an isolated [15:23.400 --> 15:24.400] phenomenon. [15:24.400 --> 15:31.200] It's part of a growing movement within the NICs community to try and structure the fundamentals [15:31.200 --> 15:36.800] of the ecosystem, starting with something that Domain briefly mentioned, which was the [15:36.800 --> 15:42.520] NICSOS Foundation Board, which got expanded a few months ago to try and be more proactive [15:42.520 --> 15:53.040] within the community and expand on his previous role, which was mostly pay for the infrastructure. [15:53.040 --> 15:57.280] And this also materialized with the emergence of a lot of different teams. [15:57.280 --> 16:01.960] The marketing team, which was created a bit more than a year ago than a team dedicated [16:01.960 --> 16:07.240] on the documentation, which I think nearly every speaker here at some point say that [16:07.240 --> 16:09.680] the documentation is a problem for NICs. [16:09.680 --> 16:11.760] So everyone agrees that this is a problem. [16:11.760 --> 16:18.280] Another team that got created around the maintenance of NICS packages, which is correct me, but [16:18.280 --> 16:23.320] I think that's the seventh more active GitHub repo. [16:23.320 --> 16:29.480] And well, when you have something of that size, you'd better not have it just be something [16:29.480 --> 16:36.760] informally maintained by whoever happens to pass by and want to make some changes. [16:36.760 --> 16:43.120] So all that is part of a big community movement about organizing these kind of things, which [16:43.120 --> 16:49.000] makes me very happy and very hopeful for the future of the NICS community in general. [16:49.000 --> 16:54.080] And since I want to leave some time for questions, I'm going to stop right here. [16:54.080 --> 17:00.000] And if you want to know more after that, we can always have a chat or contact me wherever. [17:00.000 --> 17:07.000] Thank you. [17:07.000 --> 17:10.840] Thank you for one or two questions, depending on the size. [17:10.840 --> 17:13.120] Are there any questions? [17:13.120 --> 17:23.440] So, maybe not directly related, but so when, if ever, we'll play speed at the ball. [17:23.440 --> 17:24.440] That's a big question. [17:24.440 --> 17:26.440] So the question was, yeah. [17:26.440 --> 17:34.200] Okay, the question was, when, if ever, will flakes be the default with a commenter by [17:34.200 --> 17:40.920] someone who might not name who say that it was in the embargo and I couldn't answer that. [17:40.920 --> 17:46.600] And so the answer, well, one answer is when it's going to be ready. [17:46.600 --> 17:54.160] And actually, so a huge part of the NICS team discussions were about refining the semantics [17:54.160 --> 18:00.800] of flakes to make sure that all the little corners that we wanted to have cut before [18:00.800 --> 18:05.000] actually making it stable were cut. [18:05.000 --> 18:12.120] And so I would, I would definitely wouldn't advance a date or a time. [18:12.120 --> 18:18.920] But it has been, it's progressing, which doesn't answer your question. [18:18.920 --> 18:19.920] I know. [18:19.920 --> 18:43.360] Okay, so the question was how we were considering project like TVX, which is a re-implementation [18:43.360 --> 18:49.040] of NICS, and whether we wanted to engage with them or whether we were already engaging [18:49.040 --> 18:50.560] with them. [18:50.560 --> 18:55.800] So I think I cut that in my screenshot here, but actually one of the explicit goals of [18:55.800 --> 19:01.400] the team was to actually engage with any third party that like that could be interesting [19:01.400 --> 19:08.760] to engage with that obviously included the TVX guys, which we didn't do because, well, [19:08.760 --> 19:14.520] people never do what they say, you know that, which is definitely something that we want [19:14.520 --> 19:15.520] to do. [19:15.520 --> 19:22.520] But in the case of TVX in particular for two reasons, one of them being that TVX was really [19:22.520 --> 19:26.960] born out of the very frustrations we talked to at the beginning. [19:26.960 --> 19:30.880] So it would be interesting to have their feedback on whether they feel that things are moving [19:30.880 --> 19:32.920] in the right direction. [19:32.920 --> 19:39.320] And also because, well, let's be honest, having another implementation of NICS, which is kind [19:39.320 --> 19:43.720] of a concurrent, it's a real off the pain like these people are doing what we want to [19:43.720 --> 19:49.360] do, but it's also great because they are like the TVX people came every once, you know, [19:49.360 --> 19:55.040] why, for example, with opening an issue saying, oh, there's this very, very weird piece of [19:55.040 --> 19:59.800] semantics in NICS when you trigger this specific, in this specific code. [19:59.800 --> 20:01.560] I don't know whether that's a bug or not. [20:01.560 --> 20:05.920] I'm probably going to reimplement it for TVX because I want to be bug by bug compatible. [20:05.920 --> 20:08.800] But is this really what you intended? [20:08.800 --> 20:18.040] In general, the answer is no, but my point is that I think we would gain a lot from collaborating [20:18.040 --> 20:19.040] a bit more together. [20:19.040 --> 20:41.560] Hopefully that's going to work.