3 ms·

This is my favourite response. As a manager, I actually really like working with devs that just put their heads down and churn through tickets. My focus is try

by trog 4y ago

This is my favourite response. As a manager, I actually really like working with devs that just put their heads down and churn through tickets. My focus is trying to implement the business strategy and having developers that allow us to execute by building what is needed is excellent. Developers (and I include myself in this bucket as I am 1000% guilty of it) are very easily distracted by The New Shiny, and sometimes it's irresistible to dive off into rabbit holes under the guise of 'learning new things'. Too many times I've ended up with massively over-engineered solutions that use experimental stuff that adds business and/or operational risk. I know how soul-destroying it is to simply sit there pulling ticket after ticket though so I carve off time explicitly for self-directed learning & [what I hope are] fun little skunkworks projects. My goal is to try to find a balance between executing business strategy and continual improvement and development (heh) of my team. But your solution sounds awesome. I would love my team to get more involved in open source projects & might suggest this as something to do as part of their usual workload. I wish I'd spent more time doing this when I was more actively programming myself.

pabs3 4y ago
Some potentially useful advice below. Remember to apply it to all the software you use, including operating systems on local machines, company infrastructure, things you deploy in the cloud etc. Possibly your team has added workarounds and technical debt to your codebase for issues in your dependencies, that is probably a good place for them to start. It is also nice to give back to projects by working on "papercuts"; things that are easy to fix but annoy lots of people (Ubuntu did this for eg). Working on bigger stuff is good too, like fixing all crashes or adding important features from the roadmap etc. https://ubuntu.com/blog/tag/papercuts https://ubuntu.com/blog/tag/papercuts https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above. Some open source projects have a list of ways companies can support them with resources (like sponsorship, download mirrors etc), for example here is the one for Debian: https://www.debian.org/intro/help#organizations https://www.debian.org/intro/help#organizations It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. Some projects like Samba do not allow corporate copyright ownership. For other open source projects, having a diverse copyright holder base of individuals and a broad contributor community helps protect projects (at least those that are copyleft) from license and other changes brought on by company acquisitions, industry competition and other corporate influences. https://sfconservancy.org/contractpatch/ https://sfconservancy.org/contractpatch/ If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too. https://blog.opensource.org/what-is-an-open-source-program-office-and-why-you-should-have-one/ https://blog.opensource.org/what-is-an-open-source-program-o... When setting up an internal "open source team", the FOSSjobs website and the other job aggregators linked from the FOSSjobs resources wiki might help you hire new open source folks. https://www.fossjobs.net/ https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources https://github.com/fossjobs/fossjobs/wiki/resources PS: if you need advice more specific to your situation, see my profile.
- trog 4y ago
  > Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above. We have this as an unwritten policy at the moment (... that I have been trying to get formalised for a while & need to follow up!). > It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. This is an excellent idea - thanks. > If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too. We are not quite big enough (yet) for this, but something like this is already on our radar. We have a pretty major dependency in our stack that is starting to look a bit abandoned & have been idly discussing the possibility of hiring someone to maintain it. Appreciate the feedback!

by trog 4y ago

pabs3 4y ago

Some potentially useful advice below. Remember to apply it to all the software you use, including operating systems on local machines, company infrastructure, things you deploy in the cloud etc. Possibly your team has added workarounds and technical debt to your codebase for issues in your dependencies, that is probably a good place for them to start. It is also nice to give back to projects by working on "papercuts"; things that are easy to fix but annoy lots of people (Ubuntu did this for eg). Working on bigger stuff is good too, like fixing all crashes or adding important features from the roadmap etc. https://ubuntu.com/blog/tag/papercuts https://ubuntu.com/blog/tag/papercuts https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above. Some open source projects have a list of ways companies can support them with resources (like sponsorship, download mirrors etc), for example here is the one for Debian: https://www.debian.org/intro/help#organizations https://www.debian.org/intro/help#organizations It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. Some projects like Samba do not allow corporate copyright ownership. For other open source projects, having a diverse copyright holder base of individuals and a broad contributor community helps protect projects (at least those that are copyleft) from license and other changes brought on by company acquisitions, industry competition and other corporate influences. https://sfconservancy.org/contractpatch/ https://sfconservancy.org/contractpatch/ If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too. https://blog.opensource.org/what-is-an-open-source-program-office-and-why-you-should-have-one/ https://blog.opensource.org/what-is-an-open-source-program-o... When setting up an internal "open source team", the FOSSjobs website and the other job aggregators linked from the FOSSjobs resources wiki might help you hire new open source folks. https://www.fossjobs.net/ https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources https://github.com/fossjobs/fossjobs/wiki/resources PS: if you need advice more specific to your situation, see my profile.

trog 4y ago
> Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above. We have this as an unwritten policy at the moment (... that I have been trying to get formalised for a while & need to follow up!). > It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. This is an excellent idea - thanks. > If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too. We are not quite big enough (yet) for this, but something like this is already on our radar. We have a pretty major dependency in our stack that is starting to look a bit abandoned & have been idly discussing the possibility of hiring someone to maintain it. Appreciate the feedback!