I ran across an article by Howard Gardner and Lee S. Shulman, "The Professions in America Today: Crucial but Fragile, " Daedalus 134 (3) (Summer 2005) via a book by John C. Bogle called Enough. The article defines six criteria that determine whether something is a "profession":

  1. A commitment to the interest of clients in particular, and the welfare of society in general.
  2. A body of theory or special knowledge.
  3. A specialized set of professional skills, practices, and performances unique to the profession.
  4. The developed capacity to render judgments with integrity under conditions of ethical uncertainty.
  5. An organized approach to learning from experience, both individually and collectively, and thus of growing new knowledge from the context of practice.
  6. The development of a professional community responsible for the oversight and monitoring of quality in both practice and professional educators.

Is open source community leadership a profession? What about open source software development? Engineering education? Let's start with the easy one first.

Engineering education

  1. Commits to the interest of its clients (engineers and engineers-in-training, and the organizations who hire them and benefit from their work) and the welfare of society (through the developments brought about by the engineers so educated).
  2. A relatively young but growing body of scholarly theory and knowledge on how engineering is taught and learned, and how to prepare people to teach and learn it -- along with a rich, long history of practice which may not have been "formally" (read: academically) recognized in full.
  3. Teaching engineering, teaching the teaching of engineering, and conducting research on and around the impact of that teaching is a specialized set of skills unique to the field.
  4. Most of my first-year classes are about developing the capacity to render judgments with integrity, particularly in research. We borrow from a plethora of other related fields for this -- research ethics and whatnot -- which means that even if the context is new, the thinking of practitioners on the topic is quite mature.
  5. I'm in a PhD program, which I think qualifies as "an organized approach to learning" -- but will also note that the ability to specifically declare engineering education as a primary concentration is very new (about 7 years old).
  6. ASEE and other organizations foster the development of a professional community specifically geared towards engineering education.

Verdict: Yep, it's a profession.

Open source software development

Note that I'm talking here about open source software development -- the creation of software and related artifacts via growth of and participation in radically transparent, open-licensed, and frequently online-based communities -- rather than software development/engineering, which is definitely a profession. Bear in mind that I'm hypothesizing this all off the top of my head, and a more rigorous investigation would be fascinating to do (but is outside the scope of this blog post, which I'm mostly hacking out to chronicle my brainstorms).

  1. Regarding clients and the welfare of society -- many contributors to open source believe that it's the Right Thing To Do, and many open source projects are worked on by companies who do have clients, but I'm not sure this entirely qualifies. If we're "scratching our own itches," I reckon we're our own clients... my thinking's unsatisfactorily fuzzy here, but I'll move on to...
  2. ...specialized knowledge, which I believe does exist, though it's not very well-codified. This refers not only to the technical knowledge (open source software development as a subset of software development) but also specific tools and practices unique to open source -- the prolific usage of mailing lists and chatrooms for even governance and finance issues, version control and bug trackers. Then there's cultural knowledge, understanding things like "release early, release often" and "default to open."
  3. Blending in with the above answer, I think that open source has distinctive (for instance) feature selection processes, marketing practices, and other examples of "the way we do things around here" that most of the non-open-source software engineering world finds unusual.
  4. We're developing the capacity to render judgments; there are conflicting standards of integrity and plenty of debate -- at the same time, perhaps this way is the way open source community has chosen to mature that facility. It's a dynamic, rather than stabilizing, tradition of spirited public debate and at times a deliberate eschewing of standardization in favor of trusting future generations to also make the right decision under future circumstances we don't understand now.
  5. Similarly, our "organized approach" to learning both individually and collectively is, to some degree, deliberately unorganized. That is to say, a common theme in every single "how to do open source" resource I've found, be it written, film, oral, or some other medium, has had an underlying message of "this world is unpredictable and chaotic, and you've got to get comfortable being lost, fast." The work of TOS professors has begun to codify this more, though.
  6. The question of professional communities are interesting; certainly projects themselves serve as communities of practice, though I'm not sure whether they qualify as "professional." Cross-project collaborations in the same domain -- for instance, the Desktop Summit or Writing Open Source, as well as conferences both large and small, seem like signifiers of the existence of professional communities to me.

So the end verdict here is... possibly. If open source development is a profession, it's not a very well-defined one -- or maybe it's that it looks different from most of the professions we recognize as professions, so it's hard to see it as one or a potential one. Can something with such informal transmission methods for skill, values, and judgment be called a profession? (Do we want it to be? Who cares?) And is the informality just the result of history and the relative youth of the practices involved, such that we're still usually unaware of the lack of these sorts of things -- or are we now deliberately choosing that informality, and if so is it by design and intention, or because we're reluctant to change?

Another possible answer is that open source development is not, and never will be, a profession -- it's a way of practicing the profession of software development, but not a standalone profession by itself. I'm leaning towards this answer at the moment, but I'm not sure how to pursue this line of questioning further to figure out on which side of the "profession" line it falls.

Open source community leadership

  1. We serve our communities. Our communities often exist to serve society (or create things that serve society). Absolutely yes.
  2. There's not much of a body of theory or specialized knowledge specific to open source community leadership; it's only within the last decade or so that practitioners have really started to write about it. There is a wealth of theory and knowledge from other related fields -- for instance, community coordination in non-open-source contexts, sociology and organizational psychology -- but practitioners don't tend to seek those out. I personally feel like we spend plenty of time reinventing wheels that other disciplines have long since figured out. However, I think open source community leadership certainly could develop a body of theory and specialized knowledge, and... well, that's part of what led me to grad school in the first place, figuring out more on how that kind of thing happens.
  3. If there's a specialized set of professional skills and practices unique to open source community leadership, it's probably (as of now) an unique intersection of practices from other fields; law (copyrights, licensing, patents), governance and politics (particularly grassroots movements), software development and engineering, marketing (especially newer theories and practices such as web-based marketing), and so forth. Not a problem; plenty of other fields began the same way (computer science as a mash of math, electronics, philosophy, and other things, for instance). (As I write, I'm conscious of mixing up the terms "field," "profession," and "discipline" -- I wish I had clearer distinctions as to what each term meant.)
  4. We frequently discuss ethical dilemmas and judgments among ourselves, and while there isn't a "code of conduct" formally ratified by a governing body of open source community managers, I think most if not all of us would have a very similar gut feel for what's right and wrong -- a gut feel that in some cases (licensing, transparency, etc) is different from the non-open-source norm. For instance, "it's okay for community members to be disappointed, but not for them to be surprised" is a statement likely to resonate more with open source folks than others.
  5. We completely lack an organized approach to learning. As far as I'm aware, everyone leading open source communities somewhat accidentally improvised themselves through the job, colliding with more peers than mentors along the way. A fortunate few (myself included) had informal apprenticeships; other than that, there's little one can say about "how to become an open source community leader" other than "just do it," and little about what, exactly, that sort of role requires and involves. Something to fix.
  6. The question of a professional community is interesting -- certainly things like the community leadership summit represent a first step, so I'd say "potentially emerging, check back in 5 years."

Verdict: open source community leadership could definitely be a profession, and it seems to be headed in that direction. Let's watch and help it along -- not prematurely codifying nascent things we're still exploring, but watching the maturity of the field in its own time. It'll probably be useful to look at the development of other fields and professions, and the stages and milestones that led to the furthering of their maturity. Reading suggestions welcome -- I'll be keeping an eye out for this stuff myself.