[00:00.000 --> 00:11.240]  Hi, everyone. Welcome to the community deaf room and to my talk. I want to talk to you
[00:11.240 --> 00:17.760]  about a meetup that I ran for many, many months and sometimes there were also many, many months
[00:17.760 --> 00:22.880]  in between different meetup events because we all had lives and things to do and it was
[00:22.880 --> 00:28.480]  during pandemic time. But it was a live streamed meetup about open source topics and about
[00:28.480 --> 00:34.440]  basically everything in open source, so licensing, funding, mental health in open source, all
[00:34.440 --> 00:37.840]  kinds of different programming languages. We invited some of the maintainers of those
[00:37.840 --> 00:44.000]  languages to talk to us about that language and its community. And we started it basically
[00:44.000 --> 00:49.640]  because we wanted to just learn more and what better way to just invite people to chat to.
[00:49.640 --> 00:53.960]  So there were no scheduled talks or anything. It was just panel discussions and trying to
[00:54.040 --> 00:57.920]  learn more about those type of communities and those type of initiatives.
[00:57.920 --> 01:10.560]  Oh, that went a little far. So a 2021 tight lived survey that you might have seen surveyed 400
[01:10.560 --> 01:18.880]  open source maintainers and found that 46% of maintainers are not paid at all. 26% earn more
[01:18.920 --> 01:26.520]  than $1,000 per year for maintenance work and 59% have quit or have considered quitting,
[01:26.520 --> 01:32.400]  maintaining the project and missing lack of financial compensation as their top reason for
[01:32.400 --> 01:38.600]  disliking being a maintainer. Now in yesterday too there were a lot of talks about funding open
[01:38.600 --> 01:45.080]  source maintainers and that it might not be the primary reason for open source maintainers being
[01:45.120 --> 01:50.480]  open source maintainers but in the end of the day we do need to pay for stuff and it's nice if
[01:50.480 --> 01:56.880]  you are able to pay for that stuff. But you know like beyond the projects that are maintained by
[01:56.880 --> 02:02.280]  the proverbial single individual in Nebraska there are a lot of other reasons for open source
[02:02.280 --> 02:08.760]  projects going bad and I would like to share some of those stories that I found from the
[02:08.760 --> 02:14.000]  contributing today meet up basically straight from the horse's mouth and hopefully it will all
[02:14.040 --> 02:22.800]  help us create more healthy communities. Alright so who am I? My name is Floor. I'm currently
[02:22.800 --> 02:28.280]  staff developer advocate at Ivan. Previously I was in developer relations roles at Grafana Labs
[02:28.280 --> 02:36.200]  and Microsoft and a whole bunch of open source developer tooling companies. I am a member of
[02:36.200 --> 02:40.800]  the DevOps days core team and I organized DevOps days or co-organized DevOps days Amsterdam and
[02:41.040 --> 02:47.440]  I'm in Microsoft MPP for developer technologies hence my question to Matt about community
[02:47.440 --> 02:54.480]  ambassador programs and I organize way too many meetups contributing today is just one of them
[02:54.480 --> 02:59.480]  so I have very little free time but if I have free time I spend it with my chickens and my dog
[02:59.480 --> 03:09.040]  and my son not necessarily in the order but all of those things. Alright so I love this quote
[03:09.080 --> 03:14.760]  from Rain Leander and I'm just going to say that they said this on the show I don't think they did
[03:14.760 --> 03:21.000]  but there were definitely I guess I'm contributing today multiple times but it just gives it a
[03:21.000 --> 03:26.800]  little bit more gravitas if we pretend that this was said at the meetup and they said that a project
[03:26.800 --> 03:31.720]  is only as healthy as its community. Community is at the core of any successful project without
[03:31.720 --> 03:36.920]  community a project is only technically open source because of its license but can't read the
[03:36.960 --> 03:43.680]  benefits of innovation consistent release cycle and faster response to current trends and market
[03:43.680 --> 03:51.680]  needs and my own introduction to open source was a very very positive one. I had decided that I
[03:51.680 --> 03:58.440]  want to learn Ruby on Rails and to the end I started following the Rails Girls guides and I
[03:58.440 --> 04:04.400]  found that I would get stuck on something because the guy didn't cover how I needed to do something
[04:04.400 --> 04:11.840]  for my specific setup that I needed to install an extra something something and I figured out that
[04:11.840 --> 04:17.680]  I could Google what I should do that and that is called troubleshooting so I felt really important
[04:17.680 --> 04:24.000]  and then I could go into the guides and change it so that someone else wouldn't get stuck on the
[04:24.000 --> 04:29.600]  same issue and I thought that was fantastic so someone somewhere in the world that I didn't know
[04:29.920 --> 04:35.920]  could benefit from me failing that first time and then fixing something and I was entirely
[04:35.920 --> 04:46.120]  sold on open source so while that was a wonderful first experience I also had a lot of dreadful
[04:46.120 --> 04:52.440]  experiences being in open source and I want to sort of and that was also the intention of
[04:52.440 --> 04:58.720]  contributing today I wanted to figure out you know like how can we recognize those sort of
[04:58.720 --> 05:06.240]  bad experiences that we might likely find in some projects and maybe mitigate it or at least be
[05:06.240 --> 05:13.520]  aware of those so that we can avoid those communities like the plague all right so in the
[05:13.520 --> 05:17.600]  meantime you know like fast forward a little bit I had learned Ruby on Rails I worked for a
[05:17.600 --> 05:23.040]  couple of different companies in the open source space I had been part of a couple of open source
[05:23.040 --> 05:29.440]  communities and you start recognizing sort of red flags early on so you do that by looking at
[05:29.440 --> 05:34.640]  code of conduct figuring out if the code of conduct is at the root of a repository for projects if
[05:34.640 --> 05:40.840]  there is persons that I can contact if I experience something that is not what I was expecting or
[05:40.840 --> 05:47.480]  hoping for or that there's just a generic email address or no contact details because that's that
[05:47.480 --> 05:54.080]  happens if they have a contributing file do I know if going to the project what I can contribute
[05:54.080 --> 06:00.480]  to does it set me up for me and my contribution to be a success do I know what they're looking for
[06:00.480 --> 06:08.160]  I would look at the makeup of the contributors pool do I recognize anyone does it look kind of
[06:08.160 --> 06:16.000]  diverse to me a helpful read me is certainly a really good sign I would look at responsiveness so
[06:16.000 --> 06:22.480]  how long are issues or pull requests typically open before they're responded to and then also the
[06:22.480 --> 06:27.800]  general tone are people thanks for their contributions or can they expect really abrasive
[06:27.800 --> 06:35.240]  answers and not really any love so I would look at those type of things and I as I got more into
[06:35.240 --> 06:40.640]  open source you tend to build relationships and you would hear from the hallway which projects
[06:40.640 --> 06:47.200]  are the ones that you should maybe contribute your time to and which you maybe shouldn't and you
[06:47.200 --> 06:52.640]  look at other things like do maintainers and Matt also sort of alluded to this in your earlier
[06:52.640 --> 07:01.080]  talk do they grant sort of like recognition for people making contributions do they offer some
[07:01.080 --> 07:06.880]  sort of mentoring so some more to newer people in the open source project do they spend some of
[07:06.880 --> 07:13.320]  their time mentoring newcomers to the project do if I come to a project with a with a and I file
[07:13.320 --> 07:18.320]  an issue someone picking these up and sort of mentoring me through making sure that that is going
[07:18.320 --> 07:26.120]  to be a wonderful PR in the end and do they promote active contributors to maybe maintainers with
[07:26.120 --> 07:35.320]  commit access so that was also like some of the good signs that you could find alright in 2017
[07:35.480 --> 07:42.640]  there was a open source survey that never got repeated sadly maybe they thought that the state of
[07:42.640 --> 07:50.280]  the Octaverse is the thing that sort of like replaced this and it was by GitHub and a couple of
[07:50.280 --> 08:00.360]  other companies and it was a collective responses from 5,500 respondents from over 3,800 open source
[08:00.480 --> 08:08.160]  repositories and GitHub and then 500 respondents from different platforms than GitHub and the results
[08:08.160 --> 08:13.160]  are an open data set set about among other things their experiences of those who use and build and
[08:13.160 --> 08:18.680]  maintain open source software the main takeaways I'm just going to read them out because we're not
[08:18.680 --> 08:23.040]  sure the people in the live stream can actually see this live so you know like they're just relying
[08:23.040 --> 08:29.080]  on my voice sorry documentation is highly valued frequently overlooked and a means for establishing
[08:29.120 --> 08:34.560]  inclusive and accessible communities negative interactions are infrequent but highly visible
[08:34.560 --> 08:40.920]  and with consequences for project activity open source is used by the whole world but its contributors
[08:40.920 --> 08:47.920]  don't reflect its broad audience yet using and contributing to open source often happens on
[08:47.920 --> 08:52.840]  the job and open source is a default when choosing software and I want to focus mostly on the top
[08:53.280 --> 09:02.400]  two findings of that report so I want to focus on the interactions and accessibility but in no
[09:02.400 --> 09:11.880]  means I'm negating all the other points from the survey alright from that survey nearly like 18%
[09:11.880 --> 09:15.560]  of respondents indicate that they have personally experienced a negative interaction with another
[09:15.600 --> 09:23.480]  user in open source and 50% have witnessed it between other people and negative experiences really
[09:23.480 --> 09:31.000]  have consequences for a project's health communities health 21% of people who experienced or witnessed
[09:31.000 --> 09:36.640]  a negative behavior set that they have stopped contributing to a project because of it and 8
[09:36.640 --> 09:42.160]  of them started to work in private channels more often which is also something that we definitely
[09:42.160 --> 09:50.920]  do not want so a little bit of the breakdown of the behaviors that were seen so by far the most
[09:50.920 --> 09:59.720]  frequently encountered bad behavior is rudeness 45% witness 60% experienced follow it by name
[09:59.720 --> 10:09.360]  calling 20% witness 5% experienced stereotyping 11% witness 3% experienced and more serious
[10:09.680 --> 10:16.920]  events like sexual harassment stalking or doxing are each encountered by less than 5% of the
[10:16.920 --> 10:22.360]  respondents and experienced by less than 2% but grouped together experience witnessed by
[10:22.360 --> 10:31.880]  14% and experienced by 3% and now when you think all of the survey was from 2017 surely it's
[10:31.880 --> 10:39.920]  gotten better by now I have bad news for you a report from on this foundation from 2021 that
[10:39.920 --> 10:45.920]  looks at diversity inclusion equity and inclusion in open source didn't bring a much better results
[10:45.920 --> 10:53.840]  than the 2017 one it's still a very toxic place to be and especially for marginalized folks it is
[10:53.840 --> 11:05.640]  a difficult space to navigate all right so in developer relations you asked for a raise of
[11:05.640 --> 11:09.000]  hands I don't know how many people raise their hands but in developer relations we have a couple
[11:09.000 --> 11:17.520]  of tools that measure community activity more so that's you mentioned orbit common room but they
[11:17.520 --> 11:22.320]  look more at you know where are your influencers right and what is what kind of like activity is
[11:22.800 --> 11:34.320]  taking place but looking at open source metrics I looked at two things like the chaos as an
[11:34.320 --> 11:39.720]  initiative in this space to measure community health chaos is a Linux foundation project that is
[11:39.720 --> 11:44.280]  focused and I quote from the website so they get it right creating metrics metrics models and
[11:44.280 --> 11:49.000]  software to better understand the open source community health on a global scale chaos if you
[11:49.040 --> 11:54.200]  don't know is an acronym for community health analytics in open source software and of course chaos
[11:54.200 --> 12:02.200]  gone to place this last Friday and chaos understands community health as the potential that an open
[12:02.200 --> 12:09.520]  source software community continues developing quality software chaos is helping through all
[12:09.520 --> 12:16.000]  kinds of things like templates for readme's and code of conduct and a wonderful terminology sheets so
[12:16.040 --> 12:22.360]  like they're doing a good job and then detergize in the same space of course is another company in
[12:22.360 --> 12:26.440]  that space that according to their website they improve decision-making and reporting by
[12:26.440 --> 12:31.600]  analyzing software development community activity and performance of open source projects and they
[12:31.600 --> 12:40.560]  do so across patches and forums and meetings and all kinds of stuff and a October no sorry August
[12:40.560 --> 12:47.200]  22 report looks at the communities open source ecosystem and I didn't necessarily want to know
[12:47.200 --> 12:55.080]  more about community health in the communities space but sidestep I do like a quote from Sarah
[12:55.080 --> 13:04.040]  Novotny from the time that she let the company communities community group at Google now of
[13:04.040 --> 13:10.560]  course she works for Microsoft because they all move around and she mentioned how the chop wood
[13:10.560 --> 13:16.080]  carry water is not only like sort of like a phrase that they say in the communities community a lot
[13:16.080 --> 13:22.040]  but it's actually a core tenant all of the projects and they want to make sure that everyone that
[13:22.040 --> 13:29.400]  anyone that is coming to the communities community is doing so to help the project and not help their
[13:29.440 --> 13:37.440]  company forward or be in the communities community for their own sort of like nefarious agenda so
[13:37.440 --> 13:43.160]  they they keep saying this phrase and they make sure that whenever someone is coming into the
[13:43.160 --> 13:50.960]  project with PR or anything that doesn't sort of align with what the community wants they will
[13:50.960 --> 13:57.720]  make sure that they they are very aware of that so they spend a lot of time actually doing the
[13:57.760 --> 14:05.160]  sort of unglamorous stuff like thanking individuals for their variety of contributions and not only
[14:05.160 --> 14:13.760]  when it includes code but any other contribution too and in its basics they are seeing this as a
[14:13.760 --> 14:21.360]  way to you know like pay that forward that that's sort of like that field and when someone does
[14:22.160 --> 14:30.120]  enter the project with this I don't know 10k line PR they they're made aware of Google's
[14:30.120 --> 14:35.560]  developer relation manager Ajah Hammerleys quote we don't do that here if you haven't read the blog
[14:35.560 --> 14:41.200]  where Ajah explains what that means you should definitely have a look at it but sort of the
[14:41.200 --> 14:47.440]  gist of it is Ajah says if you run a meetup or a team if you lead an open source project or if
[14:47.480 --> 14:53.680]  you organize an event people will be looking at you to know what is okay and what isn't you get a
[14:53.680 --> 15:01.160]  responsibility whether you want it or not it's yours and we don't do that here is a polite a firm
[15:01.160 --> 15:13.120]  way to educate a newcomer about your culture back to the report so Baterja the looks when they
[15:13.120 --> 15:17.360]  look at community health they look at a couple of things so one of the things is responsiveness as
[15:17.400 --> 15:22.640]  the time to solve issues and pull requests or merge requests as well as the average commits per
[15:22.640 --> 15:31.200]  day a lower average response time indicates a higher performance in the ecosystem the complexity as
[15:31.200 --> 15:37.600]  determined by the number of code repositories and the number of people involved an increasing number
[15:37.600 --> 15:46.000]  of repositories indicates in increasing complexity makes sense activity diversity as in number of
[15:46.760 --> 15:56.280]  commits issues patches requests and over a period of time and when and where that activity takes
[15:56.280 --> 16:06.920]  place sort of shows how the ecosystem is distributed they look at how talent is managed in the open
[16:06.920 --> 16:14.320]  source ecosystem and they try and analyze a different contribution different aspects of code
[16:14.640 --> 16:21.720]  contributor growth so they identify the contributor retention rate so the contributors that remain
[16:21.720 --> 16:28.840]  engaged and sort of the bounce rate so people that leave the projects and they look at the bus
[16:28.840 --> 16:37.680]  factor definitely feel like many people in the room should be aware of that factor but is the
[16:37.680 --> 16:42.800]  sort of minimum number of team members that should be engaged with the projects for it to have long
[16:42.920 --> 16:50.720]  term sustainability and they look at community footprint to and that's an interesting one it's
[16:50.720 --> 16:56.920]  the presence or an influence of organizations within the open source ecosystem so one of them that
[16:56.920 --> 17:01.800]  they look at is the gamma factor that's the amount of contributors that use a gmail account and are
[17:01.800 --> 17:10.200]  likely not contributing from sort of like a professional standpoint the elephant factor the
[17:10.200 --> 17:16.480]  minimum number of email domains whose employees perform 50% of the total contributions and they
[17:16.480 --> 17:21.840]  look at contribution patterns so for instance are a lot of the contributions done during the week
[17:21.840 --> 17:27.520]  or during the weekend if there are many of them are done by the during the weekend and likely
[17:27.520 --> 17:34.440]  there's a lot of individual volunteers contributors that are still contributing to the project
[17:34.440 --> 17:48.000]  right to a couple of the lessons learned from talking to these 50 plus maintainers one important
[17:48.000 --> 17:54.040]  thing that kept coming back in all of these meetings is how important it is to set expectations so
[17:54.040 --> 18:00.640]  the side story of the we don't do that here in the communities community is a way to model behavior
[18:00.640 --> 18:08.560]  and you want to be doing that so if problematic behavior as the ones that are described in the
[18:08.560 --> 18:16.360]  open source survey from 2017 for instance take place it is paramount to address those swiftly but
[18:16.360 --> 18:22.080]  but definitely publicly because you want to set that tone you want to show the behavior that you're
[18:22.080 --> 18:28.160]  looking for you want to model that behavior and there's ways to automate a couple of the things
[18:28.240 --> 18:35.640]  that you expect from people entering your community too so if you find yourself asking people that
[18:35.640 --> 18:41.640]  send you a pull request to elaborate on a pull request even just like even just after one or
[18:41.640 --> 18:47.480]  two times and maybe you want to make sure that you have PR and issue templates available so that
[18:47.480 --> 18:54.240]  they know what is expected what you are looking for in order for you to be able to actually review
[18:54.240 --> 18:59.920]  that that pull request so a lot of that expectation setting is something that you can automate too
[18:59.920 --> 19:07.680]  and of course licenses are a way to set expectations too right and we actually had two different
[19:07.680 --> 19:15.160]  contributing today meetups that were talking about licenses and most recent one was with clearly
[19:15.160 --> 19:22.120]  defined tight lived open source initiative and the ethical source movement and I learned a couple of
[19:22.280 --> 19:25.960]  wonderful things one of them actually if you're married to a lawyer apparently you can also give
[19:25.960 --> 19:33.640]  legal advice I don't think I was allowed to quote that one but another thing is that combining
[19:33.640 --> 19:39.360]  licenses for one project is definitely possible and I'm not talking like one one license for the
[19:39.360 --> 19:44.800]  code and then one license for documentation but combining licenses is possible but it's mostly
[19:44.800 --> 19:51.040]  good for lawyers and not for the project necessarily because you're just introducing complexity you
[19:51.040 --> 19:56.840]  will want to choose a license that is standard in in sort of the ecosystem that you're you're in so
[19:56.840 --> 20:01.120]  if everyone's using Apache maybe you want to use Apache to in your sort of like language
[20:01.120 --> 20:07.200]  ecosystem for instance and if you're thinking about building a business around your project maybe
[20:07.200 --> 20:15.520]  ultimately you need to choose wisely we talked about CLA's contributor license agreements a lot
[20:16.160 --> 20:22.680]  in one of those meetups and how if you haven't done that it's absolutely a pain to do real real
[20:22.680 --> 20:27.960]  licensing because you will need to contact all of your contributors and some of the it's it's
[20:27.960 --> 20:34.080]  anyway notoriously hard to try and contact your contributors because they often don't have an email
[20:34.080 --> 20:39.760]  address or anything listed on their GitHub profile if that's your platform of choice maybe they have
[20:39.760 --> 20:45.040]  moved on from the project some of them have maybe passed away because that's an actual possibility
[20:45.760 --> 20:51.040]  and then how do you go about that? Either way you would need to do if you do real licensing you would
[20:51.040 --> 20:56.400]  need to do a introduce a breaking change right because you're breaking your API and that can be
[20:56.400 --> 21:03.360]  very divisive in a in a community and some of the community members might refer to like little
[21:03.360 --> 21:08.800]  latest release and fork that one and create a community around that one or totally fine but
[21:08.800 --> 21:18.080]  you need to be aware of that. Also recently at Tech Press there was this project that was that
[21:18.080 --> 21:24.160]  sort of threatened to real license if they didn't get funding which I find an interesting approach to
[21:27.360 --> 21:33.200]  right originally an academic project the Postgres open source stewards are very interested in its
[21:33.200 --> 21:40.400]  extensibility and its ability to merge it with other projects so maybe one of the lessons learned
[21:40.400 --> 21:44.720]  from contributing today is to play well with others make sure that there's connectors integrations
[21:45.920 --> 21:52.880]  that sort of extensibility is an interesting thing and people look for that. Some organizations that
[21:52.880 --> 21:59.680]  are involved in open source have great policies internally or maybe in Ospo and usually that
[21:59.680 --> 22:03.760]  means that employees can make contributions to the upstream project during working hours which
[22:04.800 --> 22:10.000]  ensures activity on the project. They're professionally involved so maybe they also wear
[22:10.000 --> 22:16.560]  their professional hat I'm hoping and hopefully it means that they don't they're not just there
[22:16.560 --> 22:23.920]  with their professional sort of goggles on. You might want to steer away from single vendor support
[22:24.640 --> 22:30.160]  most all projects accept help and contributions from service providers we'll know that they're
[22:30.160 --> 22:37.200]  hyperscalers and some of them definitely appear on paper as the champion supporters of a project
[22:38.320 --> 22:41.920]  but the future requests can never outweigh whatever the community wants
[22:42.720 --> 22:50.480]  importance. A side tangent and I promise this is probably the last one but recognize red flags
[22:50.480 --> 22:57.120]  whenever a company is looking to pay you for your open source contributions or pay you as a
[22:57.120 --> 23:04.000]  maintainer and make very very sure that you don't have to subject yourself to the same OCRs as they
[23:04.000 --> 23:09.280]  have for the rest of their engineering organization because companies work at a very different pace
[23:10.560 --> 23:15.760]  and with you know financial years then open source does and it's important to know that.
[23:16.720 --> 23:23.120]  Sticking with Postgres for a little bit contributor experience is a very important thing
[23:23.760 --> 23:28.080]  I remember that Gregory Stark I don't know if he's in the room maybe not maybe he's still sleeping
[23:29.200 --> 23:36.480]  he mentioned that his first contribution to Postgres was a very positive one and that's
[23:36.480 --> 23:43.200]  something that made him want to contribute more for the long term. It can make all the difference
[23:43.200 --> 23:50.000]  in terms of gaining long term contributors for your project if that first experience is a good one
[23:50.000 --> 23:53.120]  my first experience with Rails was a wonderful one because of Rails Girls
[23:54.800 --> 24:00.080]  and remember that 2017 open source survey and how it said that documentation is highly valued
[24:00.080 --> 24:06.000]  frequently overlooked and a means for establishing inclusive and accessible communities? Well from
[24:06.000 --> 24:12.560]  the contributing to date meetup panels on docs often the conclusions were that it's important to
[24:12.640 --> 24:16.800]  create documentation in a market language that other people know so that they can
[24:17.520 --> 24:23.040]  review it maybe also contribute to it so if they find an issue like getting stuck on a certain
[24:23.040 --> 24:27.680]  something something in the Rails Girls guide you can contribute to the project
[24:28.960 --> 24:33.440]  and that at minimum the setup needs to be documented that people can usually tinker
[24:33.440 --> 24:39.680]  beyond the setup but that first step needs to be a good one and to be clear and concise to avoid
[24:39.680 --> 24:50.240]  jargon and if you use jargon then offer glossary maybe. I also love this quote about non-code
[24:50.240 --> 24:58.080]  contributions that triaging and labeling is a contribution too. Projects need to think about
[24:58.080 --> 25:03.600]  the different reasons for people to contribute to open source and they can address those different
[25:03.600 --> 25:14.720]  motivations with appropriate work. Matt said this when Matt was on our show too. So open source
[25:14.720 --> 25:21.600]  is a marathon it's not a sprint and marathons need sponsors sprints do too you can ask me how I know
[25:21.600 --> 25:27.280]  my son runs and I need to get sponsors for this because I said I do sponsors for for conferences
[25:27.280 --> 25:37.600]  I can definitely find sponsors for your sprints and we've had several contributing today's
[25:37.600 --> 25:46.480]  sessions around funding open source work and I thought this we invited Toby Langall from
[25:47.200 --> 25:55.520]  Unlock Open he's very known for saying things that are a little controversial maybe but it's good
[25:56.480 --> 26:01.040]  so companies making money of people's work without paying them is a huge liability something that he
[26:01.040 --> 26:06.640]  said which can't agree more and he continued that people don't understand what it takes to run a
[26:06.640 --> 26:13.120]  business or an open source project for that matter and nobody scrutinizes companies for providing
[26:13.120 --> 26:20.000]  healthcare or I don't know bathrooms for their employees so why are we looking putting putting
[26:20.960 --> 26:30.960]  maintainers on such a you know under such scrutiny from that same episode Phoebe Quincy was a
[26:30.960 --> 26:36.560]  senior community relations manager at Digital Ocean said that there's many projects that need
[26:36.560 --> 26:42.160]  your help more than the community's project even if you rely on the community's project a lot for
[26:42.800 --> 26:49.520]  to get your your your stuff done and also added that Hector Perfest in more recent years is actually
[26:49.520 --> 26:55.360]  looking to promote some of the smaller sort of like plumbing projects that really would need your
[26:55.360 --> 27:00.720]  help and that could use your help through using Open Collective or GitHub sponsors or any of the
[27:00.720 --> 27:08.720]  sort that sort of program Estelle well who's a technical senior technical writer and community
[27:08.720 --> 27:13.520]  engineer at Open Web Dogs also said that most sponsoring programs are small pockets of money
[27:13.520 --> 27:20.240]  just enough to cover server costs but still we treat that as this big thing Phoebe from Digital
[27:20.240 --> 27:26.640]  Ocean I quoted her before said that false funds award lump sums large amount of money and the next
[27:26.640 --> 27:32.160]  challenge is doing that consistently we found that you know sometimes projects get a lot of money
[27:32.160 --> 27:40.160]  in the one month and then nothing the next and how do you even balance that and yeah and we feel
[27:40.160 --> 27:46.000]  like this is this wonderful thing by the way like 10k is this huge amount of money while
[27:46.000 --> 27:52.240]  what do we pay software engineers at our companies in 2021 we had a very similar conversation with
[27:52.240 --> 27:59.760]  Babel Maysainer Henry who mentioned that he is scrutinized for by by the community for going
[27:59.760 --> 28:04.560]  on podcasts and doing marketing for the project to try and get more donations in while he should be
[28:04.560 --> 28:14.720]  working on the project and so he feels like he should be spending more time doing coding while
[28:14.720 --> 28:20.000]  that might actually not be what this is the best interest of the community and the Babel project
[28:22.240 --> 28:30.400]  and while a normal company would like to have a runway maybe when you're running an open source
[28:30.400 --> 28:37.760]  project that that sometimes feels like sending the wrong signal because why why are you not you
[28:37.760 --> 28:43.440]  were doing the work before while you were not paid for it so now that you're paid for it like you
[28:43.440 --> 28:53.200]  need to do xyz and this sort of like ties into a whole sort of toxic notion of we have this really
[28:53.200 --> 28:58.160]  romantic view of the open source maintainer that is in the basement of their mom you know like
[28:58.160 --> 29:07.280]  deprived of sunlight and just like suffering and only then are you a true you know unspoiled
[29:07.280 --> 29:13.680]  hacker but it's ridiculous like so for anyone who does want to pay a mortgage doesn't want to work
[29:13.680 --> 29:19.040]  at a company doesn't want to give their project away to foundation so for valid reasons I'm sure
[29:20.160 --> 29:26.720]  there is this website called oss.fund there's a lot of different ways to fund your project more
[29:26.720 --> 29:36.560]  consistently but the FOSS contributor survey from 2020 by the Linux foundation I feel like I'm
[29:36.560 --> 29:41.680]  sponsored by the Linux foundation a little I loved our talk yesterday too in the Janssen room the
[29:41.680 --> 29:47.840]  closing talk summarized the results of survey of free open source software developers with a goal
[29:47.840 --> 29:56.080]  to identify key issues in improving security and sustainability of open source and found that
[29:56.080 --> 30:02.560]  vast majority of respondents that nearly 75 percent are employed full-time so that definitely
[30:02.560 --> 30:08.720]  goes into you know like breaks with that romantic notion of the person in the basement and survey
[30:08.720 --> 30:19.920]  found that over half of respondents are paid to contribute to FOSS which I mean great and usually
[30:19.920 --> 30:28.160]  we're a little bit concerned about corporate involvement in FOSS projects but there's a lot
[30:28.160 --> 30:32.320]  that we can do there remember when I talked about mentorship like some of these people that are
[30:32.320 --> 30:37.920]  paid to contribute to open source maybe they can fulfill that role of the mentorship for new
[30:37.920 --> 30:44.880]  contributors and of course Linux foundation suggests to maybe move to a foundation with
[30:44.880 --> 30:49.520]  neutral governance to ensure diversity of organizations and control but of course the
[30:49.520 --> 30:55.120]  next foundation would say that wouldn't they all right I'm drawing through clothes I promise
[30:56.960 --> 31:01.600]  the previously mentioned report found that all types of contributors reported that they spent
[31:01.600 --> 31:08.800]  very little of their time responding to security issues and when I say very little I wonder what
[31:08.800 --> 31:14.960]  number you have in your mind but it's 2.27 percent of their time of the total time that they spend
[31:14.960 --> 31:20.480]  on the project they spend on security issues and also they indicated they have no intention
[31:20.480 --> 31:26.640]  of increasing that amount of time to spend on security issues instead they're looking at organizations
[31:26.640 --> 31:36.160]  to help them with free security audits with contributions for security and so that's something
[31:36.160 --> 31:40.960]  for anyone in this room that is working for a company that allows you to spend time on open
[31:40.960 --> 31:45.040]  source is something that maybe you can bring some of your expertise or you can find some of
[31:45.040 --> 31:50.080]  your friends in security departments and see if you can get them to help you out on that one
[31:51.120 --> 31:56.800]  I'd be remiss of course to not talk about the slity of our supply change your transitive
[31:56.800 --> 32:03.200]  dependencies are part of your wonderful community garden and it's imperative that you at least
[32:03.200 --> 32:09.120]  observe them and observe the health of that components that are literally your foundation
[32:09.680 --> 32:15.200]  all right in conclusion I wouldn't dare to suggest that open source is sick but I think we can all
[32:15.200 --> 32:22.320]  do better at taking some of our vitamins so collaboration between strangers is one of the
[32:22.960 --> 32:29.040]  most remarkable aspects of open source and if we can all be better stewards for all of that so
[32:29.120 --> 32:35.120]  set expectations upgrade your own boarding improve your contributor experience check your
[32:35.120 --> 32:41.200]  dependencies floss and prepare to do that all over again every single day thank you so much
[32:45.120 --> 32:46.000]  thank you very much