Hi, everyone, and so, yes, Brian introduced me, I'm Teofan, I'm, so I'm a member of the
NYX West Foundation Board, but I'm not going to talk about that today, because I'm also
a NYX maintainer, I have been a NYX maintainer for the last few months, and I'm going to
talk about the NYX package manager team, officially called the NYX team, but it's very confusing,
so I won't call it like that, at least not in the first slide, which is a team that
has spawned a few months ago to actually expand a bit on the maintenance of NYX.
The reason why we created this team is that NYX, in some ways, had a bad reputation, both
for contributors and for users, with this idea that the maintenance of NYX didn't care
about contributors and users, which is not great for an, well, it's not great for a product
and it's not great for an open source product, so to be fair, that's not true, a slightly
less wrong amended version would be that the single NYX maintainer doesn't have the
bandwidth to care about all that, because it's one guy hacking on a fairly big project
for a bit of history, if you don't know NYX originally, that was a PhD project that Elko
Dostra started, and then it has grown up progressively, the community has expanded, but until recently
that was still only maintained by Elko Dostra as one person, which was definitely not enough
for something of that size, but regardless of the fact that it's not someone not caring
about anything, it's really more of an organizational problem, well, that's not great for a number
of reasons, so as I said, contributors didn't really feel like they were as appreciated
as they should have been, a lot of pull requests stayed unanswered for a long time or forever,
even when they were answered, there was no guarantee that you could get an actual yes
or no answer to is this pull request something that's going to be met eventually, and there
was also no way for contributors to know before the fact whether what they were doing could
fit the NYX style guide, because there was one, there still is one, but only one person
knew it, and so as a contributor that was really, it was really tough to contribute
to NYX because of all these kind of little things, and another problem which is more
something for the users is that the release process of NYX was a bit chaotic, so the 2.3
release of NYX was somewhere around 2018, anyway, don't remember the exact date, but
then NYX went for two years without a release, and when the 2.4 release came, I just made
some quick starts, and I'm going to show up the interesting numbers, so NYX was 55,000
lines of C++ at that time, well, only counting the implementation files, and the diff between
the 2.3 and 2.4 release was 32 new lines, or lines changed, so essentially half of NYX
had been rewritten between the two releases, and as you can guess, that came with a number
of breakages, honestly very few breakages given the size of the diff, but still way enough
to annoy users, a lot of, regardless of the breakages, new features had been introduced,
but not necessarily properly documented, or experimental features had been added and were
like officially experimental, but that was not properly communicated, so people started
relying on them as if they were actually stuff that you could use for production, and then
they got changed, because they were just experimental and people got angry about that, I mean, rightfully
for them point of view, unrightfully from the point of view of the maintenance, for which
these were experimental, you should just not rely on them, but anyway, that led to a lot
of frustration, and that has been going on for a long time, I think we could say that
NYX has started being really a big enough project since the early 2010s, and it has
kept growing ever since, so the frustration has kept growing with that, so in 2018 a group
of people just sat together and decided that this just couldn't keep going, and so they
decided to create the NYX core team, whose responsibility was exactly this, like improve
the maintenance of NYX, make it clear what design decisions are, where the project is
going, what contributors can expect from them, and what we expect from contributions, so
that we could smoothen all that, so this core team was a great idea, but at least to me
at that time, I wasn't that much involved in NYX at that time, I was only a user and
very casual contributor, the main contribution for the NYX core team that I saw was one
year later another announcement that the core team was disbanded because it hadn't done
anything meaningful in that year, so yeah, that was unfortunately a bit of a failure.
Now, well, then in the meantime I came to contribute more and more to NYX, it also happened
that Elko and I got colleagues for some time, which really helps smoothen things a lot for
my contributions because I could just ping him and say, hey, Elko, I have this for request,
can you please review it, but that was really helpful, but unfortunately, well, maybe fortunately
I guess that depends, but not everyone got to be Elko's colleagues, so that model couldn't
really scale, and yeah, at some point we thought, well, we need to do something and maybe try
again with that NYX core team, well, didn't manage to do, but then the big question is,
well, how can we succeed if that core team failed?
And like for the record, that team, if you look at the co-authors here, these were the
biggest members of the NYX community at that time, that was not just a group of random people
showing up and saying, hey, we want to maintain NYX, that was really a big community effort.
So how could we make something that works, and why maybe could we make it work now?
So I'll maybe expand a bit later on the how.
The first question is, well, the first thing is that the circumstances were actually very
different.
If you look, so I dig a bit in the GitHub history stats, this is very blurry, but that's
where you won't be tempted to read all the numbers, and you will just show the big shape
of the graph.
So these are the main commuters between 2003 and 2020.
So that graph represents Elko's contributions.
And these very, very, very, very tiny graphs that, yeah, I can see that one.
It's not smaller than the pixels on the screen, but barely.
So these are the other main contributors.
So as you can see, well, that's really a one-person project with some contributors.
If we look between 2021 and 2023, and I'm probably getting out of the camera field,
so I'm going to stay where I am, well, you can see that, well, Elko is still the main
contributor.
That's no question about that.
But then things are much more well-distributed after that.
So that means that there's actually people who potentially are already investing enough
time in Nix and could really take on a mentorship.
And another key ingredient that also probably was missing at the time is that between 2018
and today, well, the Nix community has kept growing, and we have more and more industrial
players in that community and more and more people who are paid to work on Nix.
Like, well, Elko has the chance of always having been paid to work on Nix more or less,
first as a PhD student, then getting hired by a company which gave him a lot of time
to hack on it, then another and so on.
But for a long time, he was mostly the only one, at least for Nix itself.
But yeah, now things are changing, we're kind of growing up, we're a real community of people
actually handling money and having people who have time to do this kind of boring and
pay-full things or reviewing poor requests of code that someone else wrote, and obviously
I didn't write it myself, so it's not good and I don't want to read it.
But now we can leverage that.
And so that's what we did.
So we gathered a group of people, we sat together with Elko and the other people who
would be one of our team members of that team.
Everyone agreed that this was a great idea, we had a lot of disagreements on the tiny details
because obviously that's how things go.
But eventually we found that team, we announced it officially saying, hey, yeah, everyone
agrees that there's problems, so we're just going to create a team to try and solve these
problems.
We set a simple but ambitious goal for the team, which was to basically take ownership
of that Nix source code and lead it to better, to higher standards, both for contributors
and for the end users, so that contributors could know that their contributions would
be taken into account or know that they wouldn't in case these weren't things that we thought
should lend into Nix, at least they should have clarity.
And the users should know that Nix was something that they could rely on, that was robust,
that fixes were met in time, that they had clear expectations and the support they could
get.
And because Nix starts to be reasonably big, we also thought that a single team of four
or five people, well, that's already better than a team of one person, but that's still
not enough really to manage the size of the Nix code base.
Not so much the size, the code base is not that big, but the vitality and the amount
of requests and issues that come in.
So we decided that the first mean by which we would want to take ownership of that code
was to actually enable more maintainers and contributors by writing some clear contributing
guides so that people knew what to expect, by trying and grow more maintainers out of
the existing contributors' base so that we would not be a bottleneck for someone having
his pull request answered.
And as part of that stewardship also, oh, I forgot a bit of history.
So this was the main step towards that, but actually someone too decided to buy the ballot
on another topic some month earlier.
And yeah, same thing, people sat down together and decided, well, the Nix release process
is not great, we need to improve that.
Well, let's just have a fixed schedule, one release every six weeks, that's arbitrary.
Probably half of this rule would say, well, this is a bad way of doing releases, you could
just send another half would say, well, this is a bad way of doing things, just leave
that head and the other half might agree.
But anyway, everyone agreed that having that was better than nothing.
Oh, and I'm talking too much.
But then this release schedule also was something that was still in Elko's hands.
And that, like, doing a release is not a big deal, but you have to think about it.
And if you're the only one whose task every six weeks to do that, well, certainly, please
don't go on vacation at the date of the release, because otherwise you're going to annoy everything.
And please don't forget about it, because then you have, you're going to have 20 people
yelling at you because you're three days late.
So that team was also a way to share a bit this responsibility.
And well, the big question then is, did we succeed?
I hope so.
I really, really hope so.
So I don't think I gave you the date already, but we started all that last September, which
means that we are six months in.
And six months in, it's still a bit tough to see.
The main indicator I have to think that's probably we've succeeded is that we've turned
the NIC's commit tree into something that starts to look like a plausible metromap,
which is always a good thing when you're maintaining an open source project.
And in addition to that, for some less tangible factors, I think that the team is going reasonably
well and NICs is starting to move forward at a more sustainable and pre-visible pace,
which makes me very, very hopeful for the future.
And just adding two minutes to expand a bit on that because this NICs team is not an isolated
phenomenon.
It's part of a growing movement within the NICs community to try and structure the fundamentals
of the ecosystem, starting with something that Domain briefly mentioned, which was the
NICSOS Foundation Board, which got expanded a few months ago to try and be more proactive
within the community and expand on his previous role, which was mostly pay for the infrastructure.
And this also materialized with the emergence of a lot of different teams.
The marketing team, which was created a bit more than a year ago than a team dedicated
on the documentation, which I think nearly every speaker here at some point say that
the documentation is a problem for NICs.
So everyone agrees that this is a problem.
Another team that got created around the maintenance of NICS packages, which is correct me, but
I think that's the seventh more active GitHub repo.
And well, when you have something of that size, you'd better not have it just be something
informally maintained by whoever happens to pass by and want to make some changes.
So all that is part of a big community movement about organizing these kind of things, which
makes me very happy and very hopeful for the future of the NICS community in general.
And since I want to leave some time for questions, I'm going to stop right here.
And if you want to know more after that, we can always have a chat or contact me wherever.
Thank you.
Thank you for one or two questions, depending on the size.
Are there any questions?
So, maybe not directly related, but so when, if ever, we'll play speed at the ball.
That's a big question.
So the question was, yeah.
Okay, the question was, when, if ever, will flakes be the default with a commenter by
someone who might not name who say that it was in the embargo and I couldn't answer that.
And so the answer, well, one answer is when it's going to be ready.
And actually, so a huge part of the NICS team discussions were about refining the semantics
of flakes to make sure that all the little corners that we wanted to have cut before
actually making it stable were cut.
And so I would, I would definitely wouldn't advance a date or a time.
But it has been, it's progressing, which doesn't answer your question.
I know.
Okay, so the question was how we were considering project like TVX, which is a re-implementation
of NICS, and whether we wanted to engage with them or whether we were already engaging
with them.
So I think I cut that in my screenshot here, but actually one of the explicit goals of
the team was to actually engage with any third party that like that could be interesting
to engage with that obviously included the TVX guys, which we didn't do because, well,
people never do what they say, you know that, which is definitely something that we want
to do.
But in the case of TVX in particular for two reasons, one of them being that TVX was really
born out of the very frustrations we talked to at the beginning.
So it would be interesting to have their feedback on whether they feel that things are moving
in the right direction.
And also because, well, let's be honest, having another implementation of NICS, which is kind
of a concurrent, it's a real off the pain like these people are doing what we want to
do, but it's also great because they are like the TVX people came every once, you know,
why, for example, with opening an issue saying, oh, there's this very, very weird piece of
semantics in NICS when you trigger this specific, in this specific code.
I don't know whether that's a bug or not.
I'm probably going to reimplement it for TVX because I want to be bug by bug compatible.
But is this really what you intended?
In general, the answer is no, but my point is that I think we would gain a lot from collaborating
a bit more together.
Hopefully that's going to work.