… 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:
Figure 1
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)

Figure 2
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.

Figure 3
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

2 Responses to … a view from Outside

  1. 1) Don’t fear. The differences are probably more subtle and not so much radical by themselves. The only become radical by summing them up. ;-)

    2) One difference is that the VCS isn’t something internal, it’s something public. That both means that every commit can be and possibly is going to be scrutinized by people that might be outside the compa…, er, organization. That can include black hat hackers! Also, there are contributors whose patches flow into the VCS that only commit one or the other patch but are not working full-time on our products.

    3) Being open doesn’t just mean that every commit in any somewhat important repository needs review, it also means you should put your hacky scripts into a maybe personal but openly accessible repo, that there’s always people from outside your team coming in and giving you comments (like me here) or advice (and therefore a number of decisions can take longer due to public discussions happening on them, sometimes with very passionate participants – as being mission-driven produces lots of passion) – and that you get to have fun in your work time with people on IRC who don’t even work with you (they may just be volunteers from outside the actual organization)! ;-)

    • Robert – I agree that openness is key, and that the pluses outweigh the minuses. I’m already enjoying that part! (Yet still adjusting.)

      My only clarification is re: “people on IRC who don’t even work with you” – my experience so far is that they are working with us (and often quite passionately – which is awesome). :D

      Yes, that is a bit of semantics, but it is one main difference between my past jobs in the corporate world, and my current life in Mozilla. That one fact makes such a huge difference.

      Thanks for the encouragement!