This is a short essay to put our high-level strategy into words. Please share any thoughts or suggestions about these words by commenting below.
Janitor high-level goals:
- We want to modernize software development
- To do this, we must first unlock innovation in this space. We do this by offering a common development platform, upon which every developer can build. Improvements instantly benefit everyone because they are shared by default (as opposed to scripted tweaks on your own laptop or GitHub profile).
- We leverage this common platform to aggressively automate the most time-consuming tasks and workflows, once and for all (it’s worth investing a lot in automation because it impacts every developer, not just your own set-up).
- We also combine the most advanced tools efficiently, keeping tools and processes up-to-date for everyone (we can kill deprecated software and inefficient processes today).
- We want to share efforts and benefits with all open source projects
- Share build resources and caches by default. Nobody should have to compile on their laptop anymore, nor set up complicated toolchains on their own.
- Share specialized tool configurations and project workflows with everyone. Nobody should have to be an expert at every tool to become productive.
- Share productivity insights to improve together.
Bottlenecks we currently face:
- There are few actors involved (Mozilla is somewhat involved, we’d love to have Google and the Linux Foundation on board, and we need a process to recruit organisations faster)
- There is still little automation (e.g. no shared artifacts or CI integration, we need specialist work, and a process to recruit specialists faster)
- Developers resist change (current mindsets are tied to local development. We could try highlighting inefficiencies and egotism of unshared local solutions EDIT: with more diplomatic words)
How we can get past these bottlenecks:
- We should get better at on-boarding new project communities
- What worked: Adding Servo got us a bit of enthusiasm and traction
- What didn’t work: Adding KDE didn’t do much (mostly because we didn’t communicate with the KDE community)
- What we need:
- Good examples how to communicate Janitor with project communities
- A process to recruit enthusiasts / Janitor project admins
- We should better encourage specialists to contribute their solutions on Janitor
- What worked: Adding Servo and Thunderbird to Janitor (we paired up on implementation, which took just a few hours)
- What didn’t work: The way we run Docker containers is still inefficient (we found no Docker specialist willing to help us improve it)
- What we need:
- A process to get 1:1 time with specialists to implement a solution via pair programming
- We should address problems where local developers don’t have a good solution yet
- What worked: Our automated environment bootstrap is super helpful (our 1-click containers have clear benefits vs painful manual bootstraps especially on non-premium hardware / OSes)
- What didn’t work: Our in-IDE “Reviews” panel and our Run button project scripts are still relatively unknown (because we didn’t communicate about them much)
- EDIT: Actually we did somewhat, e.g. Coder206 in his 2017 DevFest talk, and both panel and button are getting some traction now. Still worth it to communicate more though
- What we need:
- To identify more fixable pain points
- A process to communicate our existing solutions to the right audience
Tentative Janitor “SWOT analysis” (EDIT: I’ve obviously never done this before):
- Amazing community
- Great benefits & results
- Great sponsored hardware
- No communication
- Very few reviewers (my review lag-time hurts our productivity)
- Windows support is doable, and can generate a lot of traction
- Many great open source projects would be easy to add to Janitor
- Involving Google
may give us access to GOMA(EDIT: seems very hard today), and to distributed build insights
- It’s uncertain how long we’ll be able to use our sponsored hardware
- There is little adoption outside of the Mozilla community