New software products start with a vision, solidify as a product plan, and are fully realized through design and engineering. A few days ago, Mark wrote about the clarified vision of Webmaker, then Erin followed up with what that meant to Webmaker as a product. This post is about that third corner of the triangle, the implementation. I’ll mostly focus on how Webmaker has affected the architecture of Mozilla Foundation projects,
which means Jess is on the hook for a post about Webmaker design Jess writes about the design over on her blog.
The rest of this post steps through the key changes we’ve made in how we work, what we work on, and how it all fits together. If you’re interested in contributing to Webmaker as a developer, this is a good overview, you’ll need to jump into the mailing list if you want to start contributing code right way.
I didn’t read any of the prerequisites
If you didn’t read the links above, here’s the story so far — The Mozilla Foundation wants to teach people how to make the web. Mozilla Webmaker: a quick way to make, remix or tweak a webpage or video while learning how the web works.. This means that the bulk of projects the Foundation has been working on now fall under the Webmaker mission, Thimble, Popcorn Maker, Webmaker.org are all Webmaker tools. As someone progresses in their mastery of the tools and concepts, they earn Badges which they push to their Backpack, which will one day help them figure out the next thing they should learn. There’s really more to it than that explanation, you should read Erin’s post.
If you looked at MoFo projects in the beginning of the summer, you’d see teams dedicated to a single project, each with their own platforms, project management tools, testing practices…islands of development that all got along, but mostly worked independent of each other. The teams got a little closer in the June / July push to Thimble, but we had to really squish the islands together to start working on Webmaker.
Lots of organizations would just give up and die at this point. Not MoFo, the developers here are the most easy going, open minded people I’ve ever worked with. This wasn’t an exercise in protecting turf, from the beginning it was about figuring out how to make the large vision that pulled all our products together work. There was negotiation, but every negotiation ended with compromises that each team was happy with. It was way smoother than anyone could have anticipated. These are some great people.
The biggest decisions we had to make,
- Server side platforms aren’t uniform, should we push towards a common platform?
- We track bug’s and features all over the place, do we unify the bug trackers?
- We manage the projects in the individual bug trackers, how do we express cross team dependencies?
The answers to the above are kind of obvious, not super complicated, but still took a couple of weeks to work out. Picture a montage of lot’s of discussions about tools, failed attempts to organize with the wrong tools, wrong approaches to the right tools, all ending in a giant group high five freeze frame.
Here’s where we ended up,
- Asana tracks the projects, specifically new features and daily tasks. Asana is where the engineers go to figure out what to work on next, and where the product teams go to figure out what should be built after that. It’s a great tool, really well thought out, and easy to use. We still need to work out the details of what it means to work in the open, and build a community around the development of the products with Asana, but we’re confident we’ll figure it out.
- The whole development team meets with the whole product team once a week. By the end of the meeting, engineers know what they’re working on until next week’s meeting. Sounds ideal, right? It’s a total lie. It’s not this easy. It’s a bunch of work. Every completed task is a victory worthy of a million high fives.
- Server side decisions are still up to the individual product teams, but a series of services will decouple the architectures enough that there’s no advantage to unifying the platforms. Which means we’re still proudly a Djangoplaydohpythonnodejsexpressmysqlmongodb shop.
Services We Need to Build
Once we had the logistics of how we were going to work as a team worked out, we started talking about what exactly we were going to build. This is going to be an on-going conversation over the next couple of months, but we made a few decisions immediately that we’re moving on now.
Single Sign On – If you sign into your account on http://thimble.webmaker.org, you should be signed into http://popcorn.webmaker.org automatically, and you should be able to manage your profile (including seeing what badges you’ve earned) on webmaker.org. Persona manages authentication, but we need a service that authorizes an authenticated user to an application, and keeps the user logged in across apps.
Open Badger – I’ve written about it before, but to issue badges across the applications, we don’t want to duplicate the work of creating and maintaining badge systems.
Unified Publishing – All of our projects publish something, each of them use different storage systems and different security models. If we offer publishing as a service to our tools, we can consolidate backups, consolidate security and make developers feel are warm and special.
Project Database – Before you start working with a tool, you pick a learning project. The projects are described in a couple of different ways. If you want to make a list of available projects across tools, it’s not easy. It should be easy. The same goes for making a list of everything everyone has ever published with the tools, or anything a single user has published with the tools. We need services that make these queries simple.
Make it all look good – Not really a service, but everything needs to look like it’s all one. Jess, Chris and Kate are way on that. They already have a three stage information architecture in mind, and the start of a style guide. We’re still developing new stuff as they figure out the design, so engineering is working really closely with these folks to keep things fast and loose.
Make it work for everyone – Webmakers cross languages, cultures and devices. We need a common way of internationalizing, localizing and making the apps and sites accessible to a variety of devices.
Build it Right
We’re going to bring a lot of new work to Mozfest, some will be in production, some will be there purely to get feedback. It’s going to be an amazing couple of days. MoFo engineers are going to spend the time working with people working with their tools, figuring out how to make them better. MozFest is our next big milestone, it’s also our next big proving ground. We refuse to release bad products, so all of our timelines are based around the question, “how much time is it going to take to put something out that we can all be proud of?” The best way to figure that out is to start working and see how things shape up, if you want to be part of the discussion, join the Webmaker mailing list, or join our weekly community call.