Janitor Master Plan


#1

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:

  1. 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).
  2. 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):

  • Strengths:
    • Amazing community
    • Great benefits & results
    • Great sponsored hardware
  • Weaknesses:
    • No communication
    • Very few reviewers (my review lag-time hurts our productivity)
  • Opportunities:
    • 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
  • Threats:
    • It’s uncertain how long we’ll be able to use our sponsored hardware
    • There is little adoption outside of the Mozilla community

Proposal: Allow users to provide their own Docker hosting
Discourse image is pretty awesome!
Sharing efforts and benefits with all Open Source projects
#2

Also, at some point toward the end of the year, it would be cool publish a 2017 retrospective, and what to look forward to in 2018.

Maybe something along these lines:

  • 2017: Alpha phase was a success
    • We significantly lowered the barrier to entry for new contributors, for several major open source projects
      • TODO: data and insights
    • We proved that it was possible to modernize software development at scale
  • 2018: Beta phase will get us to the next level
    • We’ll massively improve the scaling of containers running on our cluster
    • We’ll support Windows, and hopefully MacOS too, allowing you to work on all platforms easily
    • We’ll go beyond Mozilla with new open source projects and partnerships
    • We’ll make it much easier for anyone to join our Docker cluster, and to add projects to Janitor
    • We’ll significantly improve Janitor’s user experience with a new design and radical automation

#3

The Cloud9 loading screen blurbs?


#4

Excellent idea! EDIT: For project-specific features, the “right audience” part could be done with project-specific Cloud9 configurations.

I also thought about having a “Features” page on the website, with screenshots / GIFs / videos to showcase our coolest features (both to document them for existing users, and to inspire newcomers to try Janitor).


#5

Actually, real-time collaboration is one. Sometimes we’re troubleshooting project issues by sending text comments to each other (on GitHub or Bugzilla or via email), and this can take many round trips / cause a lot of confusion.

Cloud9’s collaboration feature is so awesome that you can directly invite people into your workspace, or visit other people’s workspaces (with their permission), and quickly fix issues by tweaking the source files and interacting with the Terminal. We already have a few success stories with this (e.g. from the Kinto team), but we just need to make Cloud9 collaboration possible in Janitor containers.


#6

As well as letting people see your NoVNC or access an application-specific port (for example, letting other people access your sandboxed Discourse instance). Those should mostly be the same, since NoVNC uses the oauth2 system the same way that container-specific web apps use it.

I have no idea how much Cloud9-specific logic we’d want, though.


#7

You’re right, maybe we don’t need Cloud9-specific logic at all (since it already natively supports collaboration, e.g. when you open an IDE URL twice, you should be able to “collaborate” between tabs, see the other’s cursors and selections etc).

I’ve added some details on how we could tweak the Janitor API to support shared access to container ports in this comment.

Actually the only Cloud9 logic we might want to add is to replace the Share feature with something that will use our new Janitor container sharing API.