Hi I’m a member of the DSF’s Fundraising Working Group and wanted to hear from people who have direct experience with workplace programs that allow/encourage Django contributions during paid working time.
I’m particularly interested in hearing from people that fit one of these descriptions:
Currently work at an organization has a workplace program that would allow for paid working time to be used on open source contributions
Have successfully or unsuccessfully tried to advocate for and/or implement something like this at their workplace
Are currently interested in advocating for something like this in their workplace (regardless of if they have or haven’t tried advocating for something like this before)
I’m curious about the following (if applicable to your situation):
What is your experience with programs like this?
What did/does the program look like in practice? (e.g. 10% of time each week, 10 hours per month, adding specific open source tasks to your company’s project management software like Jira, etc.).
Were you happy with your experience? What would have made your experience better?
Any other related thoughts and experiences welcome, of course; thanks all.
PS: This doesn’t quite feel like a “Show & Tell” post but I wasn’t sure where else to put it so here we are
Currently work at an organization has a workplace program that would allow for paid working time to be used on open source contributions
This really only happens for me when it aligns with an obvious need for the business. For example, django-simple-history didn’t support a bulk create operation with update_conflicts. I was able to go make that upstream change. That’s one example, but it’s happened at least a dozen times for various projects. Especially when we upgrade Django versions.
I’d like to start making more asks of the company for either time or direct dollars, but there’s a good measure of fear there.
Probably close to 100% of the contributions I made during the last 10 years were on company time. The alternative would’ve been telling my boss “Hey, sorry, there’s a bug and nobody will fix this so we need to abandon the project/feature/bugfix” and I don’t think that would’ve been any easier to accept.
On the other hand, when I had to fix or change something and the upstream repo didn’t seem reactive or especially open to contributions, I confess I didn’t even bother submitting a PR.
Also, being the CTO allowed me to decide that contributing (ideally with eventual PR) to open source was A Good Thing, and the other members of my team contributed as well to a number of projects.
Updated to add that we didn’t really quantify the contributions - rather, if a given change to a library was required for any reason to complete a task, it was simply done.
Historically when it’s been a small patch that has affected my workflow I have pushed bug fixed upstream to the relevent libraries or have mentored others to do it. Typically this has been third party libraries and not Django itself. Or we have spent time splitting out appropriate work and open sourced that as a package.
That said, I’m interested in this as I hopefully transition into a CTO role as I would like to bake this into the engineering culture, that we give back in terms of time & finance to Django community, so I’m interested to hear from those that have made this work!
The previous company I worked for had a program where you could take a small number of hours a month (I think it was 8 hours a month, or like 2 hours a week) for professional development stuff. You had to say what you wanted to do in that time and they would approve it if they considered it relevant to your professional development.
The company I worked for used Django as one of its main frameworks, and when I was a Djangonaut in Djangonaut Space Session 1 I successfully advocated to be able to use those professional development hours for the Djangonaut Space program. I left the company shortly after the program ended so I never got to ask if those professional development hours could be used for open source contributions outside of the scope of a structured program, I’m not sure what the answer would have been if I had asked
The previous company I worked for had a program where you could take a small number of hours a month (I think it was 8 hours a month, or like 2 hours a week) for professional development stuff. You had to say what you wanted to do in that time and they would approve it if they considered it relevant to your professional development.
Same exact thing at my previous company. “10% time for R&D” was prominent in their recruiting materials. You qualified for the program after six months. Most people weren’t proposing projects like “contribute to open source,” but I had a history of contributing already and made a case for why continuing to contribute would be a good fit for my professional development (and would fit my learning style). The paperwork was kept to a minimum – the proposal was supposed to be roughly proportional to the time investment: either spin up a short ticket for a tiny task, or make a markdown doc for an ongoing effort, just to ensure feasibility. I said I would focus on migrations/ORM/GIS, since SQL & PostGIS were where I wanted more skills. Short monthly updates. I added a generic ticket “Django R&D time” to our sprint board and would share what I worked on during our retros. I think there are two commits signed with my work addresses before winds shifted after that company was acquired. I was grateful for the time, since it came during a period when I wasn’t contributing to Django very much.
Elsewhere, I’ve found managers have no problem with spending work time submitting a thoughtful bug report. Sometimes if the fix is trivial I roll it in with the report. Obviously being a prior contributor makes this easier to pull off as the total time invested doesn’t raise eyebrows.
There’s one ticket I could make a business case for fixing, but I mentioned it to a junior colleague and got them interested in trying their hand – just need to wait until we both have capacity to give it a go.
My team uses Friday afternoons for reading technical content, experimenting in our codebases, trying new tools, and contributing to the open source libraries we rely on. So that’s a potential four hours per week.
We also fit contributions in between blocks of feature work if it makes sense. However, if we would directly benefit from an open source contribution, we will add it to the normal development schedule. This has been rare though.
I’m a member of the DSF’s Fundraising Working Group and wanted to hear from people who have direct experience with workplace programs that allow/encourage Django contributions during paid working time.