January 22, 2012

… a View from Outside

tl;dr

One of the things that excited me about the opportunity to work at Mozilla was the chance to change perspectives. After working in many closed environments, I knew the open source world of Mozilla would be different. And that would lead to a re-examination of basic questions, such as:

Q: Are there any significant differences in the role a VCS plays at Mozilla than at j-random-private-enterprise?

A: At the scale of Mozilla Products [1], I don’t believe there are.

But the question is important to ask! (And I hope to ask more of them.)

Summary

So things are different at Mozilla, but isn’t that always the case when changing jobs? Well, yes, but Mozilla appears to be more different:

  • We’re guided by our Mission Statement.
  • We produce open source products.
  • We’re owned by a not for profit foundation.
  • Much that most companies would consider “trade secrets” or “proprietary information” about process or plans, we discuss in public.

But, how different does this make the inner workings of Mozilla? As a release engineer, how would my day-to-day work change? How much of what-I-thought-I-knew need to be thrown out? Would I be putting myself into an “everything you know is wrong” situation? [2]

I’m sure I’ll be dealing with this cultural shift for at least my first year. I’m looking forward to this, as it will be a wonderful opportunity to examine a number of assumptions I’ve mad for years, that may no longer be useful. (And, even if one assumption is discarded, I don’t know if it will be replaced by one that contradicts the original, or subsumes the original with a more general understanding of the process.)

For example, one such question I’m currently pondering is: what is the role of the VCS (version control system) in an environment like Mozilla? Does it differ from private enterprise? If so, how? This question is one I’m keenly interested in, both philosophically, and practically. As is often the case, writing about it clarified some things for me. I hope folks who comment will help polish it further.

What Services are provided by a VCS

One might (and I suspect many readers will) think this is a silly question. A VCS exists to support developers. Period. Historically, that’s a very valid point. If one is just looking at software development, we can put the development team in the center of everything:

digraph dev_silo { rankdir = "LR" developers [shape="circle"] VCS [shape="box"] developers -> VCS [arrowhead="open"] VCS -> developers [arrowhead="open"] }

Most development operations now have a number of automated systems which interact with the VCS, including:

  • defect tracking
  • continuous integration
  • metrics (code churn, bug density analysis, etc)
digraph sw_dev { rankdir = "LR" developers VCS [shape="box"] developers -> VCS [arrowhead="open"] VCS -> developers [arrowhead="open"] VCS -> "bug tracker" VCS -> "build sys" VCS -> metrics }

Toughest of all to spot are the non-automated policies that rely on certain behavior being stable over a long period of time. These implicit contracts impact operations such as:

  • legal audit trails [3]
  • disaster recovery plans
  • the big boss’s custom metrics script that assumes things don’t change.
digraph bus_interest { rankdir = "LR" developers subgraph cluster_1 { VCS [shape="box"] developers -> VCS [arrowhead="open"] VCS -> developers [arrowhead="open"] VCS -> "bug tracker" VCS -> "build sys" VCS -> metrics } VCS -> subgraph cluster_2 { "audit trails" "disaster recovery" "unknown reports" } "bug tracker" -> "audit trails" }

I won’t attempt to draw it, but now imagine that every data store and automated process in those diagrams need to be replicated or clustered for scaling and HA. All of a sudden, our nice neat little VCS system has gotten out of hand. Any change has to meet the needs of the entire user community, not just the developers.

[1]Here I’m using “product” to mean something that is produced my Mozilla and installed on end user devices. (Firefox, Thunderbird, Seamonkey are all examples.) Mozilla also provides services, which may have different needs.
[2]This is what programmers were told when they started to program the first Macintosh, as it required a change from procedural flow to event driven flow. Of course, that was a huge lie, as many programming fields already used event driven programming. (Even RPG II, but that’s another story.)
[3]Mozilla has these - the commiter’s agreement combined with commit level authorization
Posted by Hal Wine
Filed under: Mozilla
Tags: culture