Awesome, so we're almost at time. This next session is about recognition and why it matters
for sustainability. Projects rely on far more than code itself. And when that work stays
invisible, people tend to leave. Please welcome Jim Madge.
Thank you. Right, so self-raising Lazarus, all contributors and how open source
can rise again. So I thought that title was very clever and funny, but I've realised
it's actually maybe not very easy to understand. So this is a depiction of the raising of Lazarus.
This is a miracle of Jesus. So friend of his Lazarus was dead four days and Jesus arrived
and rose in. Now, in the English-speaking world, we have something called self-raising flower.
That is flower which has eleven-ing agents in. So when you make a batter or dough, it rises
on its own. It's got everything it needs to rise. Hence self-raising Lazarus as a joke.
Now, this is Malcolm, no, this is not Malcolm Tucker. This is Peter Crowdy who plays a character called
Malcolm Tucker in the show called The Thick of It. And in one scene, I like very much.
He says, this is a sense of depth to our sensibilities. He says, you're looking at Lazarus
to eat arts and not just plain Lazarus, I'm self-raising Lazarus. So not only is it a difficult
to understand, it's a joke that I still. But I like the title because one, I really like that
quote, I think it's funny. And also it reminded me of how oposos projects can sort of survive a death
and actually they've got the stuff they need to come back. So yeah, this is a story about
open source in the small community projects. It's about volunteer labor. It's not about
big commercial back projects. It's about the day-to-day struggle of volunteers and then
actual kind of turnover. But yeah, so it's a little about the difficulties, but there's
also some joy and I think it's about how projects can come back and like self-raising
flower, how oposos means all the ingredients are there because something's come back.
So a bit about me, I love free and open source software and everything open. I work as a
research software engineer in the UK. I'm a steering committee member for the terrain
way, which is a collaboratively written guide for open reproducible ethical
data science. More recently, I decided to make some contributions to
Jupiter book, which is a subject of Jupiter. And most recently, I've decided to take on
this, being a maintainer of all contributors. This is me. So I can 94. My mum's taking the
picture and I'm telling her there's this man from Finland on the use net group who's made
a free operating system that we should really have a look at. So we need to know a bit
about all contributors. All contributors is a project all about recognising the
contributors to our open source projects. And the diversity of the types of
contributions they make and important that means it's not just about code. It's a
number of things. There's a specification which enforces things like the
record of contributors must be prominently displayed. It encourages categorisation
so to show the types of contributions people make. And it also discourages certain things
such as trying to scrutinise the quality or size of contribution. It's not about
who's the best contributor, who's the most active contributor. It's about what people
have brought to a project. In practice, that's a JSON file. And so managing that by hand
is not fun. It's our approach. So there are sets of tools also. There's a CLI which
doesn't most job of managing this for you. And I think probably the way people interact
with this, the most, it's probably the bot. So there's a, there's a get her bot.
And just by leaving comments in poor requests or issues asking the bot to add someone
it will, it will come along and they can report requests making those changes for you.
And I think, if I'm, that's, that's caught in my speech.
It's the access communities where you might have maintainers, community managers who
want to get involved in this sort of thing, but wouldn't be so happy using the CLI.
The project has maybe not a huge, but I think quite a sort of passionate
views, and I think there's some common things we can say about the people who use this project.
The, the projects who really want their contributors to feel valued and, and recognize
they're often projects where there's a lot of work which isn't represented in the
committee history. So I think lots of community management work, promotional work,
maybe finance and sustainability, that sort of thing doesn't, doesn't show up in
it, but is, is critical, really, really important. I think there's sort of an interesting
cluster of projects which are kind of academic to adjacent to academia.
And I think maybe that's what's something to do with. There are, there are similar
conversations going on there about what taxonomies should be used for crediting people
with research, how do you acknowledge people who are contrary to research, but are not
as of other paper. There's an interesting kind of overlap there. And because you can
generate with the, with the, with the CLI, these nice HTML tables, sharing all the
contributors, I think, your projects where there's some significant presence on the web,
whether that's the thing you're making is, is web based or or a documentation site.
They tend to use it a lot. As an example, if the internet is still working, the
training way, which I mentioned earlier, which I work on.
Yes, this is the on this page on the training way where we have a table of, of
the contributors, the little emoji tell you what sort of contribution types they've made.
So that's a little example of what it might have got like.
But all is not well. And if you were paying attention on GitHub, you probably would have
noticed some bad signs. It's been quite a while since there were any releases.
So the pensies are now quite old. There were a lot of issues hanging around, whether
that book reports or feature requests. I think things weren't getting done.
In general, not much engagement from the maintainers. And I think sort of pulling on the
idea, like I said, this is like value. There are people who really care about this.
They read it like this. So how does that happen? What's going on? Part of that, I think,
is two few people. It's a man's of work. This is number of people.
It just wasn't making sense. Of the people that do contribute. Of course, they've got
lives. They've got things to do. I don't think we can hold it against them for saying that
their family or their work might come before this sort of hobby.
Burn out a lot of interest. I think maybe for this particular case probably more on the
loss of interest side. It's completely fine to really jump into something and have a
lot of fun. If it starts getting boring, if it starts getting like a chore,
I think that's fine. That's just natural. People are going to want to move on.
Something else with that time.
Another important point which I've heard Mike McCoy talk about this room in
previous years is which I quite like. It's this idea of having a pipeline to
take people who are users, to an image of contributors, and actually hopefully
turn them into maintainers. I think that just wasn't happening. You could see
there were occasionally some users who would make occasional contributions, but
very few people sort of got to the point where they were really active in
maintaining the project beyond something like I want to add a feature which I
personally would like to see.
Focus a little bit. Bus factor. I think it was a problem.
The GitHub organization, a few and five people were able to pay maintenance role
of those. I think approximately zero were active.
Crowd in which is the platform for managing translations. There were two people
to manage that. The worst thing hosting the domain and DNS was completely
reliant on one person.
This sort of talks about a resurrection.
A resurrection has to be a death. The sort of trigger for this was the
the all countries as website disappeared.
People started noticing.
Lea Weser, who is the founder of PiOpenSy, was one of the people
that noticed and kind of started a conversation.
I saw on MasterDawn and it sort of broke out into various
groups. People saying, that's really disappointing.
We feel this is important. We don't want it to go away.
There are people saying, well, what can I do?
I'd be willing to step up and help.
It's a small team that has started to form.
I think this is roughly who we are at the moment.
There's there. I am there.
Of these people, Josh has contributed to the project before.
Maximilian has contributed and has done some maintenance work
in the past, but it's sort of gone dormant.
Yeah, he's keen to help again.
We wouldn't be possible to all without support
from previous maintainers and they can help for
and they are involved in helping us sort out things,
but they're not in a position to come back
and play a very active maintenance role.
So we got together.
Christine and I talked about what's the plan
and what are we going to do?
The first thing we decided to approach was documentation.
The reason we came to that was it seemed like the urgent thing
that the doc says is down.
That's fixed that.
I think we kind of felt documentation is quite a good way
to start learning a project.
You get to see a bit of different things.
It was also, perhaps, a way to avoid
jumping into JavaScript and a code base we didn't understand
right away.
So we're all much more comfortable with Markdown
generating a static site.
So we got dug in and there were a few challenges there.
So I think not surprising given that there hadn't been maintenance.
A number of dependencies were very old,
several major versions old full of vulnerabilities.
The site was built using docu source,
which I had not seen before,
and that was a number of major versions out.
So it was going to require some changes anyway
and some people in the team were kind of opinionated.
I don't really like this, I'm not sure, for Rastro.
This feels like an opportunity will switch.
And so the similarly in the documentation,
there were some things which were now old enough
that they were just kind of out of date.
So it wasn't the easiest task,
but we could see a route through.
And yeah, we got stuck in project boards,
got working on that.
We also wanted to make sure we were sort of building in more resilience,
because that seemed to be a problem.
And I think a lot of the work was really sending emails
being very patient for people who we completely relied on
in some cases the only person who had access to the DNS.
We just need to work with this person,
but there was a very time pour.
So it has to be sort of quite a lot of efforts and patience
and understanding on our side about the speed at which
those things like move.
I'm happy to say where we are now,
the site is back, so it's online,
and it's sort of important that it's back under our control.
So I think this is updated and any changes we want to make.
That's fine, we're no longer sort of relying on people
who are sort of difficult to contact,
if we're to get the attention of.
We are, as of maybe two weeks ago,
we're starting now to shift focus to the CLI.
Some of the problems there, lots of other dependencies,
a lot of untangling bits of code that have been deprecated,
finding replacements, and getting control of bits and infrastructure there.
So I think we're quite hopeful that,
or at least going to have a patch for these where the update is
when you install this or no longer shout out to you about
millions of vulnerabilities and the URL packages.
The bus factor has significantly improved,
I mean, I think domain and DNS two people,
so it doesn't really feel terribly comfortable,
but we're in a much better position than we were.
Unfortunately, I'm really kind of,
I'm disappointed, I'm kind of upset that in this migration,
we decided getting a website back up and back under control
was worth temporarily losing the translations.
I think that bothers me, because it's really important for accessibility,
and that's something we really want to move on to,
but it just seemed like the best compromise at the time.
Yes, so where we're going now,
a short term, get those translations back,
like I said, make a release of the CLI,
and just make sure we actually go access to all of the infrastructure,
the various bits of things that the bot run,
build and see eyes and things,
longer term, I think we really need to think about this issue of,
how do you get your users,
and turn them into contributors so that they're sort of
that to the engaging and reporting,
and that there's a much clearer route to,
if you want to get involved with this matters to you,
you can get involved,
and hopefully avoid this sort of low again.
Yeah, and then eventually move on to thinking about,
where do we want this to go?
Can we start picking up some of these bugs that have been around for ages?
What features do we want to add?
Yeah, so there's some challenges,
we're not all super familiar with whichever script,
that we found, but I think we've got this assistance,
and we're all quite keen.
I'm hopeful of the future.
Some lessons, probably not a simple one,
but build and resilience from the ground up.
It's way too fragile to have things depend on a single person.
It's also way too fragile to have things depend on individuals,
really, you need to be thinking about what teams of people
are going to manage things, how do you organize the teams?
Folks on what you can do,
and I think the flip side of the other way to say that is,
don't worry too much about the things you can't do,
so there might be something that's very important,
if you're not unable to do it,
it's maybe not worth worrying about it too much.
I'm not sure if this is one of these might be a bit controversial.
I think in bases going slow, community project like this,
you've got to protect your own sanity and happiness,
it's not going to end of the world if things take a bit longer
than you would have hoped.
Mason's before features,
like I was explaining earlier,
like having the site there,
the fact that it's there, it works, it's usable.
Okay, that's fine.
There's loads of stuff we'd like to do and could do to make it better,
but there's that baseline of,
can you use this,
and I think that's the critical thing,
I'm sorry, I didn't remove all that.
But the world bike shedding,
bike shedding is spending,
as of unreasonable amount of time,
fussing or worrying,
or taking action on things which are not important.
And I do,
I think I'm reflecting a bit on,
maybe it was that,
was the doc's reading most important thing,
maybe we should have,
with the jumped into the cell I first.
I'm not too sure.
And another sort of reflection,
when as I was digging a bit into the
doing it with get archaeology,
looking at the contribution history,
it's sort of hard to figure out exactly what happened,
but I think,
it's probably isn't the first time this has happened,
you can sort of see,
looking through who's contributing,
looking at the frequency of commits,
there are definite peaks and troughs.
There's an initial flurry,
whether the spec and the CLI are written,
there's a bit of a quiet period,
there's another flurry where someone's working on the,
the GitHub bot,
and there's another quiet period of maintenance,
and I think there's a different thing,
most recently,
was that it wasn't a quiet period of maintenance,
it was sort of a flat line,
nothing was happening at all.
But it's sort of isn't the first time this has happened,
we're not the first teams to kind of
breathe some life back to this project,
we might not be the last,
and so yeah,
I think the most important lesson is,
if there's a community,
if there are people that really value something
and really care,
then our projects can come back.
I hope the source comes out again.
So thanks so much for listening,
I'd especially like to thank your own
Magnus who's the original Crater and maintainer,
Kent Dodson, Jake Bellum,
who are a table of very important role
and maintenance,
therefore having to get us together.
Everyone who's contributed all contributors,
and also the trainway,
can you can describe area,
some of the other stations,
you can sing,
have been made by them,
so they talk would be a lot more boring without those.
If you want to get involved,
if the sound is interesting,
use the button, your own projects,
recognise all of your contributors
and all the wonderful things they do,
you can read the dots,
if you're interested in joining,
please reach out,
we're looking for people to help.
Yes, thanks very much.
Time for some questions.
Anybody have any questions?
I'm just curious,
how did you regain control over your project
in terms of GitHub permissions and write?
Or was it in your team already,
someone who has admin rights?
Did you say permissions to write?
The permission of GitHub rights,
like GitHub rights?
Yeah.
So the question was,
how did we get the permissions we needed
to start maintenance?
Was someone in our team sort of already had those permissions?
Sort of.
So I suppose the initial thing was,
we were opening issues,
on repository saying,
does anyone have access?
What's going on?
We would be willing to help out.
I suppose Maximilian was the person
who did have permissions
and was sort of paying attention to that
and helped us sort of get on board a bit.
But yeah, overall,
we couldn't have done it without those people.
There were a few places where we cut things out.
So originally all the CI was on circle CI
and we've cut that out and we're using GitHub actions
and that was a place where we could do that.
I think that the hostings on that defined,
I think that was another place where we decided,
okay, it's just going to be easier to set up a new team
and start fresh.
But some of the things like the DNS and GitHub,
we really needed those people.
So some of that was people noticed on GitHub when we asked,
some of that was we did some digging to find emails
and send emails and we're very polite and patient.
But yeah, we couldn't have done it without those people.
And there are the interventions, the helpful and enthusiastic.
Any other questions?
Let's take an example and have like,
imagine you have a project that you expect
to communicate to die for a few years
and then resurrect at some point.
Do you have any tips for the maintainers,
I guess, but I'll get a big bug before everything shut down.
Like is it documentation for,
I mean, you don't try this documentation the same for tomorrow
and for next year, I guess.
So any tips?
Yeah, the question was,
if you expect a project to go through
have some flows and maybe quite a down or down a dive for it,
what can you do to make sure that people are able to pick it up in the future?
I suppose what I can say is what we found difficult
and I think yeah, we should be really careful
to think on that and try and maybe make sure we do a better job.
And I think you are right in suggesting documentation.
And particularly, it's that kind of developer documentation.
So we're finding bits of infrastructure which are kind of important
for maybe running the GitHub boss or testing that.
And we just didn't know it existed.
It's not written down anywhere.
Or it might be written down somewhere, it's very obscure
and a kind of a bleak reference and it just really makes sense.
So I think really documenting who has access to things,
what different, what you're,
a piece of the infrastructure are, what they're for.
Even in really very simple terms,
we're super, super helpful.
I think we just had one more question, right?
You're good?
Okay.
All righty.
Anyway, thanks, Jim.
Thank you.