Hey everyone.
Everyone's ready for some,
learning about some sustainable open source development.
What?
What?
Okay, cool.
Hey, so I'm going to be talking today about human essentials,
and that's how you can find it on GitHub.
A little bit about some of the best practices we've done,
hopefully have a little bit of a discussion at the end.
I tried to save a little time in the talk.
So hi, I'm Sean Marcia.
I'm a software engineer on GitHub's social impact team.
I'm also part of Ruby for Good.
I love baking. I'm a Zimergist.
I'll let you Google that.
And I'm from the Washington DC area,
so if any of you are planning on coming to Washington DC,
or you're from there, reach out.
I'd love to take you out for a coffee or tea,
or whatever your beverage of choice is.
I guess everyone found out I was speaking,
because they're all rushing in.
And I'm going to be talking about the Human Essentials app.
It's a couple of fun things.
We are a digital public good.
Got our certification last year.
We won the 2022 Pizzagatti prize from N10.
And so audience participation.
Who's familiar with the concept of an Essentials bank?
Okay, there's one person.
A co-worker of mine.
So Essentials banks, well, that's actually not why she's familiar,
but Essentials banks are things like diaper banks,
peer supply banks, adult and continence banks.
They operate on the same concept of like a food bank,
where they don't give food directly to the public.
They give it to organizations.
They give it to the public.
So like a diaper bank collects diapers and things like that,
and gives it to like homeless shelters, women's shelters,
like high school programs, things like that,
that are distributing directly to the public.
And these are the organizations that Human Essentials software serves.
And just a couple of quick facts about diaper banks in the U.S.
is just last year, 40% of the families in the United States
relied on or had diaper need.
And like the last time they did the survey was in 2010,
and it was 33% of the families.
So things are maybe getting a little bit worse.
And of those families suffering from diaper need,
25% of them had to miss work because of that.
And the reason why they miss work is you can't put your kid into daycare
unless you have diapers for the kid.
And if you don't have diapers, you can't put them in daycare.
Well, then you can't go to work, and then you don't have money,
and you have less money, and it's this vicious, you know,
negative feedback loop.
And the same thing too, like 28% of these families
often had to choose between buying food for their kids or diapers.
And just, it's not a good situation for families in this situation.
And so like our software, some facts about it.
Now we have over 240 banks across the United States,
and some in Canada now registered using it.
And like I said, they're on the partner system,
and so we have about 5,000 community partners.
Our project started in 2015, and it's now helping over 3 million kids a year
and over 500,000 period supply recipients.
We've had over 300 contributors on GitHub, which is pretty cool.
We're endorsed by the National Diper Bank Network
and the Alliance for Period Supplies.
These are the two big national networks in the United States.
We're digital public good, like I said, which we're super stoked about.
And we're 100% volunteer driven.
Like we've never had a paid person, and we don't charge anything
to all the diaper banks and peer supply banks using the software.
So yeah, like are we a unicorn?
Like how did we do this?
Like how did we get here?
And so kind of first of like background before we kind of get into that,
some background information, basic kind of things,
is like we have like a team etiquette, which really is three things.
It's to be patient with people, be helpful, and be kind.
Like we really believe that it's much better to be kind than to be right.
And so, you know, like kindness really matters,
and like that is our ethos with our teams and our contributors,
which I think, you know, is why we have so many people.
And also like just kind of like some basic like stats to like, you know,
we have a readme and GitHub, we, you know, we have a contributing guy,
like all the little things to make it easy for someone to come to the project
and just get started.
And importantly, we have a code of conduct.
Just like, you know, they said there's a FOSDEM code of conduct.
A lot of people don't realize that if a project doesn't have a code of conduct,
some companies are actually prohibit their employees from contributing to those projects.
So if you have one of these projects, make sure you have a code of conduct.
And it's the right thing to do.
And, you know, I think we highlight this in our contributing guide.
Like, you know, we start off like, hey, code of conduct is important,
but then like you see this like, like, hey, if you're unsure of anything,
just submit a pull request or an issue and just ask.
No one's going to yell at you.
We're not one of those evil open source projects.
Because, you know, open source can be intimidating for people for the first time.
And so, you know, we just say, hey, give it your best effort,
and we're going to make this a welcoming place for you.
And GitHub also makes this really easy for projects.
Like, if you've ever been on the Insights tab and the community standards,
like it lets you know if you have all these things.
And if you've never been in the Insights tab, like I'd say, go check it out today,
especially if you're data driven, because there's a lot of really good information
just about like the cadence of your project and just what's happening.
And it'll really, yeah, give you some insights that you may not be aware of.
And like another kind of background thing is, it's important to know who is contributing
to your project and why they're contributing.
And, you know, like we've had over 300 contributors to our project,
and like, we've tried to talk to them and understand why they come and contribute.
And we've found that it's really for four reasons.
Like, the first reason is, is like they want real world experience working in software.
You know, like they can build to do apps or they can build things,
but like there's no replacement for, you know, like your resume
or if you want to show, like highlight work, then a real project.
You know, because maybe they're coming from like C++ or Rust or some other language
and they want real world, you know, Ruby on Rails experience.
And so like this gives it to them.
Some people are here because, you know, just like everyone at Fosdm,
they believe in open source software and they want to contribute to open source software.
Some people are here because they believe in the mission
and like, like perhaps they, they benefited from a diaper bank at some point
or they have a family that has or a friend and they want to contribute for that reason.
And the final reason is people just want to be part of a community.
Like they want a group of friends because, you know, we are all friends
on the kind of the maintainer team.
We get together on regular cadence, we chat and zoom.
And so, you know, they want to be friends with like-minded people.
And I think these are the best people around.
And on the other side of that is like, what's important for a maintainer of a project like this?
And like for us, a maintainer is someone who doesn't write code.
A maintainer is someone who makes it easy for other people to contribute
and to write code and to, you know, write assets and to manage a project.
Like our general belief is a maintainer should be writing code 10 to 20% of the time
and the other 80 to 90% of the time they should be facilitating everyone else being successful.
Because, you know, rather than just being one person, they can be a force multiplier for a lot of people.
And then the last kind of bit of background information is, you know,
it's important to understand the type of project it is too.
Like this is a, like human essentials is a SAS. It's not a library.
Like when you're maintaining a library, there's a lot of things to think about like
backward compatibility and like does it run in all the different versions of the language,
all the different frameworks. But we're a SAS.
Like the number one thing we have to be concerned about is user data.
Because, you know, we're dealing with such like vulnerable populations.
So we have to keep that data safe. And so that guides all of our decisions.
Okay. Now that we've got the background of the way, like what works?
And again, this is what works for us. And so your mileage may vary.
So the biggest thing that I think that works for us is the human impact.
Like there are a lot of amazing open source projects out there,
like talking to a bunch of them just in the hall before I came in here earlier.
Like there's a lot. But these type of projects, like, you know,
these digital public goods, like we have something that all these other open source projects don't have.
Is we have like the human angle, the human impact that no one else can,
like those other projects can't in my opinion, compete with.
So we take advantage of that. Like when we're writing our issues.
You know, we could write an issue that says, hey, when we click this button, it sends an email.
Which is, you know, is accurate. But, you know, like we'll always tie our issues.
Or we try to always tie our issues back to the human impact.
So contributors know who they're helping and how they're helping.
So, you know, when we click this button, it sends an email to remind a family to come, you know, pick up their diaper supplies.
You know, so, you know, so they're able to get to work that week or be able to work that week.
Maybe that's a little contrived. But we're always trying to write, like highlight the human benefit.
And the other side of that is, you know, we try and facilitate as much stakeholder interaction as we can.
So we have regular meetings with different diaper banks, period supply banks.
So contributors, you know, can meet, can talk to, and really understand, like, this code they're writing and contributing to,
who it's helping and how it's helping them.
Because, like I said, like there's no substitute for actually hearing from the people you're helping, how you're making their lives better.
Consistency, like, again, like being consistent has really helped us maintain our contributors.
Like we have, you know, we have a public calendar. We list all of our meetings on there.
We have regular check-ins with our stakeholders. We have regular office hours.
We do deploy same time every week.
Like, even if we don't have a deploy, we send emails out, like letting people know why.
Maybe it was Christmas or maybe we're in the middle of something large.
But, like, always regular communication, both the stakeholders with contributors.
Another thing we benefit from is being part of Ruby for Good.
And Ruby for Good is a nonprofit that builds software for other nonprofits.
Like, maybe Code for America or Code for France, or like these organizations that run several software projects.
And they have a couple big events each year where they get a lot of, think of them as code retreats for nerds,
where they get a bunch of nerds together at a site.
It's kind of like all-inclusive.
So, like, they do coding during the day, and then at the night they do a lot of community building,
like playing board games, seeing karaoke, sitting around a campfire, making s'mores.
But so, there's a lot of community building around the teams, as well as doing good.
And it's also a great time for the teams to do a lot of, like, in-person, like, road map,
and just, like, the deep work needed for these projects.
And as well as, like, the Ruby for Good kind of events or conferences,
we submit the Human Essentials Project to a lot of Ruby and Rails conferences,
because, like, it's a Ruby and Rails project.
So, like, RailsConf, RubyConf, RailsWorld, we'll submit it as a workshop event where we will create 20 or 30,
like, really small issues for people to contribute to, and run the workshop for people to contribute,
make their first open-source contribution.
And so, they will come out, we will facilitate them, like, writing code,
making an open-source contribution to Human Essentials.
And generally, we start these with also with bringing, like, someone from a diaper bank out
or peer supply bank, and giving them, like, a five or 10-minute, like, just a little talk on Human Essentials,
on, like, diaper banks and what they do.
And again, like, to tie these people, like, to the work they're doing,
and, again, putting a human face, like, hey, like, I'm going to write this code today,
and it's going to help this person, which, again, like, I think is a really special thing about,
um, what we're doing.
Uh, Slack, we're heavy users of Slack.
Like, we, uh, we're part of the Ruby for Good Slack, which is really nice,
because there's all these projects in there.
And so, if we're ever stuck on something, we can put out, like, a call for help,
hey, we need, we need advice on this, and people from other teams will come and, you know, help us.
Um, but we have a public channel, we have, like, a bot channel that talks,
the bot channel is really spammy, but it's talking about the pull requests and issues and everything coming up.
We have a lead channel.
Uh, the other thing we did is we set up a Slack, a separate Slack instance for the banks and their partners,
which, which actually turned out to be a really good idea, because, like, now that there's so many of them,
uh, like, initially it was just kind of a, like, in their minds a place to come and get tech support,
but, but now it's kind of turned into, like, a community for them,
and it's actually, we're, we're now, like, kind of flies on the wall in there, like, listening to them, talk to each other,
and, and more interestingly, like, we hear how they're using the software, because it's not always how we built it,
or we intended it to be used, and so, but, like, this lets us help them, uh, you know, in a way we weren't intending,
because, like, oh, this is how they're actually using it, so, you know, so we can make, you know, this, this, and this better for them.
Uh, you know, we're big fans of continuous integration, uh, every, every bit of code that gets submitted gets run through,
like, a battery of tests, and linting, and, you know, um, breakman, like, security vulnerability checks, all, all that kind of thing,
because, again, like, we don't want to protect the data, we want to make sure nothing bad is coming in.
Uh, in, in fact, we use GitHub pretty much extensively for all of the, uh, parts of the project,
uh, like, dependabot for keeping all our dependencies up to date, and security, uh, continuous integration, like I said,
uh, project management, like all the, like, we're not using Jira or anything like that, uh, workflows, talk about workflows in a second,
love workflows, uh, you know, Wiki for information, pull request templates, issue templates, like, all the things in one place,
it's just been really nice for us, and workflows, like, workflows have turned out to be my, my favorite part of, like, the GitHub experience,
because, like, for us, it really allows us to, uh, like, offload a lot of the emotional labor, uh, of this, and, like, there's a lot of,
I see nodding heads, like, there's a lot of emotional labor to, to, uh, maintaining, like, a, a project, like, you know, someone claims an issue,
and then are they still working on it, and then you have to, like, pester them, hey, are you still doing this, and, and, that, that's hard,
and, and, like, it's hard to, like, you know, to, you know, bug people or pester people, but, like, GitHub allows us to, like, automate that,
like, we have a, like, a bot that, after 30 days, if, if an issue is, uh, stale, like, someone's claimed it, and they're not doing anything,
it'll just say, like, hey, this is, nothing's happening, we're gonna, we're gonna take you off this in seven days, then seven days later,
they get unassigned, it gets remarked, help wanted, and then somebody else can work on it, and then, like, all that, that pain of having to, like,
you know, try and, like, pester this person is gone, and also, like, the good emotion of labor, too, that maybe sometimes we forget to do,
we, um, you know, like, like, someone, here's a poll request that happened, and, you know, K-man had got merged, and then, uh, when the,
when the deploy went out, we automatically, the bot automatically notifies this, this, this gentleman that, uh, hey, your, uh, your code was included in the deploy,
and now it's out there, it's out there helping these, uh, these Depper Banks, which is awesome, um, and one just tiny little example,
uh, like, our workflows, our workflows are also, you know, if something gets merged in, okay, changes on the, uh, one of the project boards,
uh, and this, this is probably gonna be controversial for some, some of the people here, but we really feel that branches are better than forks,
uh, and, like, the, uh, and the reason for that is, uh, like, oftentimes, like, a poll request will come in, and it's, like, 99% of the way there,
like, it's just missing, like, some tag or some, uh, like, it's just missing something minor, and we could go back and forth with, with the contributor,
but, like, we found it's just easier for a maintainer to, whatever, add, you know, add in that tag or add in that one little missing thing,
and quickly merge it in, because then you get, like, a faster, like, like, feedback loop and, like, faster results for the contributors,
and, like, they're happy that this, this thing got merged really quick, and then, you know, then they're gonna pick something else up and, and,
and, uh, and get it going. But again, uh, I know that this is very controversial, some people probably, uh, think that's terrible.
Um, uh, we're also very opinionated about the code we let in, like, all, all code gets linted that comes in, we require tests,
uh, we're, we're very also opinionated on what libraries come in, we want all the libraries coming in to be boring, like, we don't, like,
if there's a JavaScript framework that's four days old, and someone wants to add it to the project, we're probably not gonna let them,
because, you know, because then it's up to the maintainers for the next however many years to maintain this thing, and it's also harder for contributors,
like, so if we are using, like, standard libraries, standard packages, uh, like, very, like, standard conventions, it makes it easy,
you know, it makes it more welcoming, more people can, can contribute, can contribute, like, regardless, uh, you know, of their level,
they don't have to know all these, uh, specialized, uh, uh, libraries. Uh, and then the other thing is, like, we use realistic seed data in the,
uh, uh, like, when you spin the app up locally, and so when you're, um, oh, everyone liked the joke. Uh, uh, uh, yeah, so our seed data is realistic,
so then if you are running the app locally, like, you can, you get the same, uh, look and feel and experience as, uh, as a bank, uh, who uses it.
Uh, we're also very intentional about how we build, uh, our teams, like, our maintainer teams, like, uh, in the early years, it was just software engineers on it and developers,
uh, but we, we quickly realized that that's a really terrible idea, uh, like, because one, because engineers don't always speak, uh, non-profit,
uh, and so, but so, you know, we've, we've made it, made it a point to add in, you know, product, product managers, designers, and really, like, anyone,
it doesn't even matter if you're technical or not, like, if you want to be a, be a part of the team and you just want to do good, like, we, we will find a way to bring you
under the team and help, and help, because, you know, uh, good people are good people. Yeah.
Uh, but again, it's, it's not all, like, uh, uh, sunshine and roses, like, there are, there are challenges to, to, uh, you know, uh, uh, maintaining a project like this,
and, um, uh, like, the big one is kind of like institutional knowledge or, like, project memory, like, like I said, our project has been going since 2015, which is nine, nine years now,
wow, uh, and so, like, it's hard to remember, like, after nine years, like, hey, why was this decision made, and why, uh, why did you do that instead of this,
and, um, uh, and, you know, like, we, we have Wiki, we have Slack history, you know, we can go look at old Git commits and, and our GitHub issues and, and, and things like that, but, like, a lot of times there's conversation in the room,
and we just don't know why things have happened the way they did, and so if anyone has a solution to this or anyone, and I know, like, there's architectural decision records and things like that, but, uh, if anyone has solved this problem, find me later,
because, you know, I would love to know.
Another challenge we have is, is tests and testing, like, um, like, you know, like, unit tests, integration tests, system tests, like, um, you know, like, obviously, we'd love to have all system tests, you know, because they really approximate a user using the application,
but then that slows your test suite down, and it slows down your feedback loops, and, um, but again, like, where, where are those borders, and, like, we're always struggling with, you know, the testing, um, and, like, and contributor feedback, like I said, like, we've had over 300 contributors now, like, we've talked to a bunch of them,
but sometimes people come, and, like, they're really gung-ho to contribute, and, you know, they submit this amazing pull request, and, you know, we merge it in, and then they disappear, and I don't know why, it bothers me, like, did we do something, because, you know, we want people to come and be welcome, because, you know, like, um, happy supported contributors, you know, these become our long-term contributors, um, and the other, the other, obviously, thing, uh, challenging thing was, like,
you know, we're struggling with a project like this is cost, like, uh, again, like, we don't charge anything, we don't pay anyone anything, but like, there still are, kind of, like, fixed costs with a project, and, so, like, how do we do it? Like, uh, like, luckily we're, we're really fortunate that, like, Microsoft gives a free Azure credits to nonprofits, so if you don't know about that, definitely take advantage of it.
advantage of it. I think it's like 3,000-ish a year, which is more than enough because
again, we're not operating on GitHub or Google scale. It's got our production server, our
staging servers, and that's pretty much it. So it's great for us. We get free email via
SendGrid for nonprofits, free air purger via bug snag. And so I think the only thing we
really pay for is our domain name, which is awesome. But I know that's a challenge, because
again too, we're also a little worried every year, like, well, what if the Microsoft for
nonprofits goes away or any of these things? How do we pay for it?
So now, if you aren't aware, I'd like to introduce you all to you for good first issue. It's
a new site we've launched on GitHub, and it's defined projects like human essentials or
like most of the digital public goods are listed on there. If you contribute to a project
or you want to contribute to a project like this, you should definitely come and check
it out. And there's a little recommended project there where you can submit your project to
be added or like I said, just find projects and it will by default list any issue in your
project that you've tagged help wanted or good first issue. So this open terms archive
here will like open up and list a bunch of the help wanted and good first issue tags
or issues. And I saved five minutes for questions. Are there any questions?
Thank you.
Not a question, just a comment. So in regards to the idea around contributor feedback where
you're like, well, we have people, they do all this work, they submit their first poll
request and then they disappear into the ether. Something I've seen work in the Kubernetes
project and the other project is having really clearly defined roles that you effectively
have a job description for and you can say like, we're looking for somebody to fill this
out. You know, like we're looking for somebody to help us do the issue triage where every
time somebody has a new issue, you go in, you ask the person, you give me more details,
because they very much say, people say, something's broken and they walk away, that's their issue.
And that's like not useful as a maintainer, right? So you say like, we need to do this
once a week, we need to do triage new issues. These are all the things involved with triaging
new issues. And like very often that's a way of getting, it's a little bit secure that
a good first issue, like that was the problem that we found in most of the C&C projects
actually, was like, you can get people to do that good first issue, but like giving them
to do a good second issue, much, much harder. But having roles helps and like really defining
the boundaries of how, of a very specific path, how somebody can deal with you, like
typically the commits follow after that. Like if somebody is engaged in say, triaging issues
once a week, it's very likely that in the course of that triage, they say like, oh, I can do that in
five minutes, I'll just do that. And then like, in the back of those, they can take on something
harder, we're going, oh, that takes a little more context, we can't try to go as a good person,
and you're like, but I can take care of it. And so that's like a way of kind of getting people to
stick, and it's also that way of like mentoring your leadership in the project. And it's also a good
way for them to communicate with work that they're doing the project externally, which has
effects on like how their, the work that they do for your open source project can help their
careers, which is realistically a thing that people want. Awesome. Yeah, no, thank you.
Also, just some comments on that. I think that it works very well with Kubernetes where it's like a multi-faceted
infrastructure with different companies at the end, so having a very clear defined role, often both,
because people do want to get involved in that, maybe because a lot of interest from their work
and work, but a lot of the time in very open communities, it may not work. One thing that we
tried at the RR project a few years ago is, in the way you get in the project, you do something,
and you find people, you interact with them in one of the community forums, and you make friends
in the new state, most of the projects we participate in because people there, there's a real
life-minded people. So we try to reverse that angle with having a funnel of getting into the project,
don't talk to people in this channel, make friends, and then we find, after talking,
then we find something that I'll be able to use. I'm going to, because I don't think the people on the
thing can hear the conversation going on. Oh, sorry, okay. So I'll open up for more questions,
and I'll try to repeat the questions too. Yeah. My question is, the platform that you built,
is it primarily targeted for these audiences, or can it also be used for other countries?
Oh, no. So the question was, can the platform be used for other countries? So it is, obviously it can
specialize, like, and the language inside it is specialized for diaper banks and peer supply
banks, but if you go to the repo, like, we have actually an entire file in there on, like, if you were
running, I don't know, like, a tool bank, or like, any kind of like donation bank platform,
you could use, like, we talk about how, like, hey, you could take this and use it right for a
tool bank, or a medical equipment bank, or, like, all these different banks that are, are exist.
When quick follow-up question, is it only in English?
Yes, the project is only in English. Yes. But if you want to translate, we'd, yeah.
You mentioned it's all 100% volunteer driven, and I was wondering if you could talk about that.
Why did you make that decision? Have you considered paying contributors in the nonprofit, I mean?
Yeah. Well, so the, so the nonprofit is also, like, fully volunteer driven, like, it's not a, like, so, like, there is no, so I
guess we have to, like, yes, we thought about, like, the, so the question is, like, have we thought about paying people, and, like,
ideally that would be great, and also to, like, kind of just giving the software to, like, if it crashed, and something really bad
happened, like, that's something that goes through my mind, because, again, like, these are all volunteers, and if things go down,
like, how, you know, we can't tell, we can't tell someone to call in sick from work to, you know, get this fixed.
I think a lot of the people in our team would, because, you know, they really care about it, but, but yes, but if you have a
way for us to get a lot of money to do this and pay for this.
It's just a funding issue, yeah.
Yeah, like, we've just, like, right, we've just kind of followed this path, and, like, ideally I think there'd be people that would
work on this full time if, you know, there was funding, but, yeah.
Right.
Are we done?
It's time.
It's cool.
Thank you, Sean.
Thank you.
Thank you.