You should learn to code.

A proliferation of online courses promising to teach you how to write computer code have attracted some big celebrity names recently, and some celebrities have even launched things. But even if you’re not a billionaire mayor, you probably should learn some coding skills. Below I offer six good reasons to try.

First, let’s be clear about terminology:

  • For the purpose of this article, I mean the same thing when I say “coder”, “developer”, “hacker”, or “programmer”.
  • When I say “code”, “develop”, “hack” or “program”, I really just mean, “create coded instructions that a computer can interpret to produce some result.” Computers are machines that implement logical instructions. Coders write the instructions in code.
  • When I say “coders write the instructions,” I mean they use a keyboard, not a mouse. Coders don’t drag & drop code. Coders do write drag & drop code, though.

Now that we’re talking about the same thing, here are six reasons you should learn to code.

REASON 1: If you learn to code, you will be a better communicator in the future.

Some autumn day in 2020, you will find yourself feeling a little chilly despite the silver bodysuit you’re wearing. So you will say something out loud like, “Hey house, please turn up the heat three degrees.” Then a computer will make the thermostat in your house rise by three degrees. But if, instead of that, you said, “Dang, it’s cold enough in here to freeze the fuzz off a snow weasel,” your house would definitely pretend it didn’t hear you.

The point is, we will soon interact with computers using a variety of inputs besides mice and keyboards, including the spoken word. But in the very near future when we speak to computers, we will have to speak to them in a dialect they can understand, just as we speak to dogs using special, limited vocabularies. And learning to code will make you much more fluent in this dialect.

cheddar-drone-03

Now: A day will come when computers also understand the part about the snow weasels; heck, in the distant future you will be able to pilot a cheddar drone using only your mind! But the road to that bright horizon is paved with a lot of zany mishaps. Meanwhile, learning to talk and think like a computer will immediately make you more confident and capable in a world full of helpful machines that don’t understand human language very well.

REASON 2: If you learn to code, you will make cool new friends!

A whole lot of people on the internet are coders and many of them spend a lot of time helping each other learn stuff. They’re usually smart and nice. And despite stereotypes to the contrary, most coders are also pretty hip.

Imagine a group of people who are so passionate about their work that they do it on the weekends, too, and then give the fruit of their efforts away for free to anyone in the world. Many coders consider this standard procedure. They do it because they love it and the community expects it of them. It is their way of influencing history. Like artists.

Now, imagine you are trying to learn to code and you run into a problem. If you diligently attempt to resolve it through reading and experimenting and you still can’t solve it, and then you ask for assistance in an online forum of coders, you will almost always get a friendly, helpful, and downright generous response from someone you’ve never met whose time is worth a lot of money. If you participate and contribute to that same community, you may even befriend or become such a person. You will thereby join a global fellowship of coders, and you can expect to receive a mysterious book of rites in the mail.

LIR: The Mysterious Maya Civilization: Pre-Columbian Era to 1825

REASON 3: Adventure, fortune and freedom await you!

There is no question that computer programming is a lucrative occupation for many people who are good at it and also for many who are not. As of this writing, a senior Ruby on Rails coder can make about fifty thousand dollars per hour. So if you like money or the things money can buy, you might want to get a job as a coder.

On the other hand, you may not care about money, in which case would you mind buying me a beer? Thanks.

That link you just clicked goes to InspirePay, a payment startup founded by Mark Fischer. Mark charges nothing for the service — so, since you’re buying, do you mind getting him a pint too?

Like many software entrepreneurs, Mark seems to be motivated in part by the sheer adventure of it. The world is stacked a mile deep in problems that software can solve. These problems will occupy software innovators for decades to come. Entrepreneurs like Mark are like early pioneers crossing the tall grass prairie, like legendary cattlemen on the high desert, like the first gold miners in the Sierras. They see the promise of adventure and they accept. They go first.

Learning to code gives you a gleaming toolkit to carry into this vast new frontier, a frontier where you will find countless opportunities to make a fortune and take wild risks. Sounds exciting, doesn’t it? I’ll drink to that.

REASON 4: If you learn to code, you can kill a lot of birds with one stone. More than two birds, anyway.

I have a friend who runs a software development firm. His firm specializes in PHP coding. (He doesn’t pronounce PHP as “fup”, but I do.)

Most software development firms get a lot of inquiries, and only a fraction of these inquiries turn into contracts. Along the way a firm often produces a proposal describing the work contemplated. This is a challenge: Proposal writing is repetitive, time consuming, and often fruitless.

So my friend wants to automate his ideal proposal generation process with a web application. He’s hacking on it nights and weekends using the laravel framework. Plenty of technology service companies do this kind of thing; some even make a business out of it it.

When he’s done, my friend will have:

  • A tool that satisfies his own business need, making his sales process more efficient and fun.
  • A software product that he can either give away to generate goodwill, or sell to generate revenue, or both.
  • Launch experience (which is the best kind) with a new coding framework (laravel) that he’s A) been looking for an excuse to work with and B) would eventually like to offer as a service to his customers.

Intimidating Swans

That is at least three dead birds; it could be more depending on how you count. So if you hate birds or something, now’s your chance to do something about it.

REASON 5: You have everything you need to start coding.

Computer programming is a difficult occupation, no doubt about it. But it does not take any more smarts than being an actuary or an attorney. It is probably less stressful than being a paramedic or a stockbroker. And it involves practically zero large predators, unlike zookeeping. Coding is mathematical and conceptual, abstract and very dynamic, and it is not for everyone. But look, you’re already on REASON #5 of a long and irritating six-reason blog post. You clearly have the most important characteristic of a good coder: speed-reading focus patience interest.

Are you reading this on a computer that is sometimes connected to the internet? (If not — if you’re reading this in print — I’d like to thank you. I’ve always wanted to be published on paper. It’s really, like, flammable, you know? Do you mind lighting a corner of it on fire right now? Wicked.)

If you have a computer that is sometimes connected to the internet and you’re truly interested in coding, then you have everything that most people who code ever had when they started. Most of them didn’t have computer science training. Many of them didn’t have college degrees at all, or even high school diplomas. All good coders are self-taught to some extent. With your computer and your interest, you can do just what they do:

  • Build a development environment — a sandbox where you can fling computer code around without harming other things on your computer that you care about. (You wouldn’t want to damage those blurry photos of enchiladas you took during that road trip to Tucson.) You can even try it out using an online sandbox.
  • Try and make something simple in code, starting from a tutorial online or from a crazy vision in your head.
  • Make lots of mistakes on the way, but who cares? You’re in the sandbox!
  • Read lots of documentation online.
  • Maybe ask some questions online, explaining that you already read the documentation.
  • Repeat these steps for a while, and do it again every time you want to learn something new.

Seriously, you can learn to code no matter who you are. Everybody starts somewhere.

REASON 6: The world needs more people who understand, care about, and can make things with the raw materials of our brave new society.

This cannot be overstated: Humanity has experienced only a few inflection points as important as the one that makes it possible for me to say this to you right now. No matter how you feel about the media, smartphones, blogs, Facebook, the internet or computers, you must understand that they are radically, rapidly transforming culture and society in every direction at once. Your financial transactions and the football scores and your precise location on earth, pictures of your baby and adoring comments from its grandmother, your job and your friends and your secrets, your final conversation with someone you love, groceries on store shelves, missiles in their silos, the stoplights and the cars waiting at them and the people sitting in the cars and the news on the car radios — all that and more every day is connected and controlled through an information network that humans created with code .

When it appeared, the printing press made written material much more accessible to many more people. Still, not everyone immediately learned to read and write. The people who did learn to read and write fully participated in the new world that the printing press made possible. They controlled economic activity. They made the government and its laws. They recorded the histories. They propagated the world’s religions. They owned a portion of the culture, and they fought for their part.

The ones who didn’t learn to read and write? Most of them saw their fair share of sunrises and sunsets, just like most people for most of history always have. But a universe of richness and capability eluded them. Fantastic novels, inflammatory pamphlets, laws and holy books: All were just mysterious symbols to the illiterate. Just like code is to so many people now.

Go to it! by drbexl, on Flickr

Today, too many smart people fear or disregard code, and shrug away their disregard as acceptable and normal. But code keeps food on our shelves. Code brings us all we know of world events. Code makes your smartphone possible. Code enables the unfettered personal expression we call a right. Code is the weapon that will win future wars. Code is the medium of future artworks. Code is the conduit of freedom.

Now, since you read this far, you obviously have plenty of time. So c’mon — why don’t you make some code? Here are a few places to start:

(This post was originally published on the dojo4 blog when I was the CEO of dojo4. I copied it here and refreshed it because I like it. It is adapted from a presentation I gave to a lunch meetup of the Boulder Chamber of Commerce’s 2140 group.)

Vouched Improvements on Mozillians.org

Back in October I wrote a few blog posts describing a significant problem with the way we admit new members into the Mozillians.org community platform. Yesterday the Mozillians.org team fixed it!

Before yesterday, everyone with a “vouched” account in Mozillians.org was empowered to vouch others. But we never explained what it meant to vouch someone: What it implied, what it granted. As a result, the standard for being vouched was arbitrary, the social significance of being vouched was diluted, and the privileges granted to vouched users were distributed more widely than they ought to be.

Yesterday the Mozillians.org development team released a major refactor of the vouching system. For the first time we have a shared definition and understanding of vouching: A vouch signals participation and contribution in Mozilla’s community, and grants access to content and systems not available to the general public.

The new vouch system includes features that…

  • ask a “voucher” to explain to the community why they are vouching someone
  • grant the “vouching” privilege only to people who have themselves been vouched multiple times
  • remove “legacy vouches” from accounts that were vouched before we agreed what vouching meant and whose current contributor status can’t be easily verified

It is much clearer now who can access non-public information using Mozillians.org (people who have been vouched because they participate and contribute to Mozilla) and how that list of people can grow (through individual judgments by people who have themselves been vouched numerous times).

When we know the composition of a network and understand how it will grow, we can make better decisions about sharing things with the network. We can confidently choose to share some things because we understand whom we’re sharing with. And we can reasonably choose to withhold some things for the very same reason. Understanding a network simultaneously encourages more sharing and reduces inadvertent disclosure.

Thanks to the Mozillians.org development team for making these excellent improvements!

Site launch: Affiliates 2.0!

Cross-posted from http://blog.mozilla.org/webdev/2014/05/21/site-launch-affiliates-2-0/.

We just launched a redesigned website for Firefox Affiliates — check it out!

New Affiliates web site!

The Affiliates website is a portal for almost 100,000 Mozilla supporters. Affiliates believe in Mozilla’s cause and want to show their support by placing an affiliate link on their website. Here’s mine:

If you use Adblock Plus you probably see nothing here. And that’s a shame.

The original Affiliates website launched in 2011. Its branding recalls an earlier era in Mozilla style. I will miss those fuzzy monsters, but (for now at least) I know I can still find them on Mozilla.org’s 404 page. And seriously, after three years, the site needed more than a brand refresh. As part of this launch we…

Image from the original front page.

The Affiliates 1.0 front page included fuzzy monsters.

  • Upgraded to the latest version of Playdoh
  • Removed lots of old code and subsystems no longer in use
  • Reconsidered and redesigned the entire user experience
  • Updated the pages to a beautiful take on Mozilla’s Sandstone theme
  • Added an affiliate leaderboard
  • Added user profiles and a personalized dashboard
  • Added space for localized news and announcements
  • Much more!

If you’re already a Firefox Affiliate, we* hope you enjoy these improvements. And if you’re not, why not sign up now? Being an affiliate is an easy way to support the efforts of a non-profit that strives every day to build the web the world needs.

We’d like to hear from you. Please file a bug if you find one or reach out in the #affiliates channel on irc.mozilla.org to say “hi”. And keep your eye out for more new features — there’s another batch of Affiliates Awesome just around the corner!

* The Affiliates 2.0 team included dozens of people spanning the globe — too many to list here. This site redesign was a collective effort of Mozilla’s amazing affiliates, volunteers, localizers, designers, copywriters, engineers, quality assurers, contractors,  and many others. Thank you all.

2114-05-15: Happy Bike Month!

The basic elements of subsistence that our grandparents learned in childhood – food, water, shelter – were missing a critical category: travel. People have a basic need to go places, and the way we move profoundly affects almost every system we can imagine: tectonic, atmospheric, metabolic, social, ecological, economic and even metaphysical. At the start of the last century, each of these systems was responding with extreme and hazardous feedback to our poor transportation decisions.

Luckily, around the same time, new tools and networks sparked a renaissance of creative, enlightened endeavor. People energetically sought solutions to many of the world’s greatest challenges. Intractable problems suddenly became addressable and their solutions marketable. Humans developed better models, better designs, and better ways of organizing around important questions, all of which led to rapid and dramatic improvements in human-created systems.

So it came to pass that a dozen new electric vehicles appeared one after another in the market. They came in lots of different shapes and sizes. They steered themselves and ran on sunlight. They never endangered pedestrians, bikes, or animals.

These new vehicles were accompanied by well-organized advocacy and their appearance coincided with several powerful political movements. Legislators and traffic planners and corporate titans had no choice: They had to accommodate a world of better transportation alternatives.

Notwithstanding the remarkable features of these new vehicles, many individuals nowadays don’t bother with the expense and bother of owning one. Moving large metal-and-plastic bodies still requires a lot of energy. Energy is still expensive. Due to shifting geopolitical conditions, first-world economies have mostly stopped hiding the cost of energy from consumers. Consumers have changed their behavior as a result. Individuals these days are much more deliberate about the geographic impacts of their choices.

Walking is so much more pleasant than it used to be when roads were hazardous and filled with noxious smoke. Short trips are also easy to take on a variety of electric conveyances, so people tend to stay closer to home most days. As you would expect, many businesses have come to recognize the value of proximity, too. Now most of us have easy neighborhood access to groceries, hardware and household goods. A robot-driven jitney is always close by if one needs to travel far in the rain.

Compared with a century ago, people today have cleaner air, cleaner water, more cohesive neighborhoods, more aesthetically pleasing public spaces, more resilient cities, more reasons to go outside, more games of kickball in the street, and more time for reflection or creation from the back seat of a self-steering car.

We simply shake our heads when we see old accounts of 20th-century drivers. They seem utterly ridiculous. Their transportation systems promised freedom but delivered economic servitude, ecological travesty, public health crises, social unraveling and a daily dose of helplessness and rage.

Since those times, many elements have combined to make things better. Someone else might argue that another factor was the fulcrum of change – solar cell or battery improvements, say, or the simultaneous rise of local governments and benevolent global institutions. But I believe life is immeasurably better now because we finally reconsidered how to get from here to there.

Motes of Dust

sunbeam

The baby raised her hands and face into a morning gleam
She'd noticed for the first time motes of dust on a sunbeam
Motes of dust on a sunbeam: I've been too old to see them shine
Now the baby's wondering delight, once before, once more is mine

A new Mozillians.org signup process

I previously wrote about some issues with the Mozillians.org authorization system. In a nutshell: The language we use to talk about signing up for (“vouching”) and accessing the platform through the API (“corporate vs. consumer”) doesn’t match our present and future needs, and also doesn’t match some of our recent practices. This disconnect has a variety of problematic ramifications. We want to fix it.

The resolution for these dual concerns is related, but we don’t need to resolve them simultaneously. Below, I describe a proposal for resolving concerns related to signing up for the platform. Many of these ideas came from williamr, jmenon, davidwboswell, giorgos, and others across Mozilla.

The problem we need to resolve is ambiguity about what it means to have an account in Mozillians.org. And, with a nod to Mozilla’s ambitious plans for community building, we need to resolve this problem in a way that makes it easy for the right people to join Mozillians.org.

Goal: Eliminate confusion about what having an account in Mozillians.org means. Make it easy for the right people to join Mozillians.org.

Those two requirements are quite complex. Opinions differ about what it means to be a Mozillian, and about how that relates to the systems that a Mozillian might join. We reached out to the community in a variety of forums to help us understand the scope of this conversation (here and here, for example). After discussing for several months, we believe the community has provided sufficient guidance for us to write code. Specifically, the community said (to use Mitchell Baker’s words),

‘[We need] to be inclusive, and provide welcome, encouragement and legitimacy to people across a range of different levels of engagement. At the same
time, we want a way to identify the set of people who are actively committed and engaged in a community of shared effort. A single “yes/no” decision — yes, you’re a Mozillian, or “no, you’re not” can’t capture all of this well.’

It’s clear that being a Mozillian is a journey. In order to support this journey, we want people who are just starting out to have access to a basic set of resources within Mozilla’s contributor ecosystem.

Mozillians.org is in a position to provide this basic level of service; for example, having an account in Mozillians.org allows Mozillians to connect with one another, lets them access certain protected resources, and makes possible a unified view of an individual’s contributions across myriad contribution pathways. Therefore, we want to build a Mozillians.org signup process that allows people to join Mozillians.org as soon as possible — at the beginning of their journey.

We want to build a Mozillians.org signup process that allows people to join Mozillians.org as soon as possible — at the beginning of their journey.

However, not just anyone can join. Mozillians do share certain characteristics and we want our signup process to capture these. The community has converged around a small set of criteria that distinguish a Mozillian. According to that consensus, in order to be a Mozillian, someone should…

  1. Be active, now or historically
  2. Self-identify with Mozilla’s mission
  3. Engage with other Mozillians in the community

We can capture all of these criteria in a signup process. In other words, we can build a harmonic coherence, building the community’s definition of Mozillian right into Mozillians.org.

cohere

Obligatory doge graphic

We’ll do this by replacing the current signup process, which depends on a vouching step, with a signup process driven entirely by invitations. Here are the specific features we propose to implement in the first iteration of this work:

  • In order to join Mozillians.org, a person must have an invitation.
  • Invites can be sent by people who already have accounts in Mozillians.org.
  • Inviting will be rate-limited (e.g. every Mozillian gets 5 invites per month).
  • The signup process will be clearly explained to logged-out users anyplace it makes sense to do so. For example, “Think you have what it takes to be a Mozillian? Great! Just find a Mozillian to invite you.”
  • The invitation process will include specific instructions including the criteria for inviting someone. For example, “Mozillians are active. Please invite people who are actively contributing.
  • All language about vouching will be replaced with language about inviting, site-wide.
  • Upon accepting an invitation, a user will be presented with the Mozilla Manifesto. Clicking “I Support Mozilla’s Mission” lets them continue to the profile creation screen.
  • The profile creation/editing screen will include links to specific information about how particular information added to Mozillians.org profiles is shared (e.g. “Information in your profile will be viewable by other members of Mozillians.org”).
  • Profiles will include an “Invited by” link to the person who invited them (people who were vouched in the prior system will be “invited by” their voucher).
  • A formal announcement of this change will be made in advance, giving all users 30 days to change or remove their accounts if they wish to.

Together, these features address the overarching goal of this effort because they clarify the makeup of our community. The new interactions and language clearly explain that Mozillians.org relies on the good judgment of each community member, and can grow organically based on the actions of any existing member.

These features also address the criteria that define a Mozillian:

  1. They specifically ask existing members to consider contribution activity when inviting new members.
  2. They require each new Mozillian to read and support the Mozilla Manifesto, self-identifying with the mission.
  3. They ensure that new members of Mozillians.org are already engaged with someone in the community.

In the future, we can imagine extending this functionality in a few ways:

  • We can allow certain API accounts to create invitations on behalf of a specific pathway. For example, when someone submits their first PR to a Mozilla repository in Github, they might get an automatic invitation to join Mozillians.org.
  • We can prompt existing Mozillians to read/agree to the Manifesto on a regular basis — perhaps annually?

We are eager to hear feedback about this proposal because we intend to start coding a new signup process in early 2014. Please reach out in the developer’s mailing list or in the comments.

A Weird Ritual

I stumbled across the short form creative brief by way of a tweet from @jmspool and I had to share it. It reminds me of something we built at dojo4 when I was CEO there, but it includes a Very Important Addition.

Technology and design work is expensive, far too expensive to do without some anticipated return (unless you work in a sector that allows you to light bricks of technology dollars afire on a hot summer day “just for the ambiance”).

When I was at dojo4, upon signing a contract with a customer, I tried to capture a couple sentences about their anticipated return on a 3″ by 5″ notecard. I pinned the notecard to a corkboard where everyone could see it (and I mean everyone: our employees, our guests, our other customers). We called the notecard the Project Compass.

The project compass was intended to be a guide, an arbiter in times of uncertainty. Whenever a question arose about project scope or direction, we could look at the project compass for clarity. A typical project compass might be “Redesign the website and add a feature allowing customers to create and manage their own profiles.”

Astute readers may notice the above compass doesn’t describe a return on investment at all. That’s quite common, unfortunately. It is HARD to achieve clarity about a project’s anticipated return. Often, a project’s sponsor has already done some initial analysis and design and is giving implementation experts the output of the initial analysis (“Redesign the website”) instead of the input (“Increase signups and improve retention”). Sometimes the sponsor can’t articulate what they hope to achieve. Just as often the implementation team can’t hear it.

At dojo4 we assumed imperfection in our project compass. Every project required a compass to move forward, but we agreed (and said out loud) that the compass might change. We even asked @anthonydimitre to draw us a classy graphic explaining exactly how this process would work:

dojo4's Project Compass, circa 2011

dojo4′s Project Compass, circa 2011

We usually dove into implementation as soon as a compass was written and pinned to the corkboard. For the minimum-viable-product startups dojo4 worked with, “implementation” was practically synonymous with “changing the compass”. But “implementation” also always meant “charging hard toward maximal features in minimal time”.

The little black “No” in the middle of the illustration above is what we envisioned happening if the project was discovered to be out of alignment with the compass. We’d look at stories and check them against the compass and change one or the other as necessary. But delivering code at breakneck pace to customers with rapidly changing goals was totally orthogonal to thoughtfully reviewing and making adjustments to paper-based project artifacts. So, our project compasses often went stale.

This is common in every kind of project everywhere. Sometimes it is a problem; sometimes not. When a project sponsor and all the project’s implementers have fantastic rapport and constant engagement, they can happily forget whatever they wrote in the brief three months ago. They’re grooving. But sometimes, the project sponsor and the implementers will carry divergent ideas of the project’s purpose all the way to launch day. I know at least a few people who’ve changed careers after pulling a week of all-nighters to deliver something that nobody wants.

That was precisely what the project compass was designed to help us avoid. But a corkboard full of stale project compasses didn’t help anything. Which is why the short form creative brief caught my eye. The document itself resembles the project compass — more verbose, still quite brief. But unlike the compass, the short form creative brief is imbued with longevity through a “weird ritual at the start of every meeting”:

One of the team members, always a different person, would read the exact same document out loud, word for word. The document, about three–quarters of a printed page, contained a tiny creative brief about the design they were working on. Reading it out loud was how they started every design meeting, whether it was a brainstorming meeting or a design review….[then] the project’s leader would turn to the group and ask the same question, “Everyone agree that this is what we’re working on today?”

Many times this exercise has no obvious impact: Everyone simply nods and the meeting moves forward. But occasionally, someone asks for clarification. They ask because they’re new to the project; or they ask because they’ve been assigned a task that doesn’t seem aligned; or they ask because they sponsored the project and no longer agree with something in the brief. When someone asks, the group discusses and updates the brief as needed.

Ritual is the perfect word for this exercise because the magic only happens if you do it religiously. You read the brief every time. You read the brief even when it feels silly to read the brief. Even — no, especially — when the meeting is about something urgent or tense. Because reading the brief puts the project’s critical facts right where they belong: At the forefront of everyone’s mind, in consensus terms freshly aligned with the effort actually underway, for the entire duration of the project.

I suspect the shape of the brief (or compass) is not nearly as important as its frequent review. Of course, it should contain enough information to explain why project participants keep meeting and working together, instead of playing pinball or hoarding shoes or visiting every county in Texas. That could be one terse sentence. The important thing is that the brief continues to explain where the group is headed, even if the group changes direction.

At Mozilla we use etherpad for planning meetings and taking notes during meetings. I have begun adding a “theme” to the top of etherpad agendas as a gentle way to remind people of the big reason we’re having yet another weekly meeting. For example, on Mozillians.org right now, the big reason we’re having yet another weekly meeting is to discuss the Curated Groups feature that we’ve been working on all quarter.

After reading up on the short form creative brief, I think I may take a moment at every meeting to speak our current theme out loud, too. Does everyone agree that this is our focus right now? Are there any questions about what it means?

We got into Wired Magazine! In 2009.

For several years my sweetheart worked in a reproductive health clinic helping under-served populations access contraceptives. One day we noticed a call for submissions to Wired Magazine‘s Artifacts From The Future section. Wired asked readers to submit their vision for the future of birth control. We knew just what to do.

I made some mockups; together we wrote the pitch.

Relax.

Relax.

Inspired by a ubiquitous cliche, we imagined a future when the after-sex cigarette would deliver a perfect dose of contraception. We called our product Afterglo, and the theme of our first campaign was, “Relax”. Naturally, the product’s most important features would be reliability and pleasure, so we highlighted those in the campaign.

Wired loved it. Their in-house designers adapted our submission for their feature. They reframed the campaign with the tagline, “Breathe Easy.” (Easy indeed: This product practically designs and advertises itself.)

When we conceived (ha!) Afterglo, major cities across America were cracking down on smokers; marijuana was still illegal in every state of the union; and electronic cigarettes were just a slide in some Philip Morris Powerpoint deck. It was pure fantasy to think that anyone would design contraceptive delivery around such a socially unacceptable activity.

That was then. Nowadays, “smoking” is back in style, thanks to the popularity of cigarette-shaped electronic vaporizers. The public health implications of this trend are still uncertain — smoke, second-hand or otherwise, isn’t the same as vapor — and our laws, as usual, can’t keep up.

But the market doesn’t care. Right now, e-cigarette liquid manufacturers are experimenting with exotic, candy-inspired flavors of nicotine (blueberry! piña colada!) that many decry as a cynical attempt to hook kids. It’s only a matter of time before all manner of alternative chemicals make their way into e-cigarettes: A multi-vitamin, some omega-3s, a few hormones, a statin (because everyone should take statins). Whether or not the FDA approves these vapors is irrelevant to anyone with a credit card and an internet connection.

Prediction: Wired’s timeline for post-coital contraceptive smokes — 2029, according to the kiosk in their illustration — is conservative!

I’m no patent lawyer, but so far it appears nobody has patented this specific application.

Proposal: The Future of Contributor Tools

I work as a web product engineer for various web products at Mozilla, including several platforms designed to serve Mozilla’s contributor community. I team up with product stakeholders to design products and I work with implementation experts to build them. I’m responsible for achieving vision.

This role gives me a good perspective on what we say we want to do and how we do it. And I see an opportunity for us to increase the scope and ambition of both in our contributor tools efforts.

In September, I collaborated with David Boswell and Chris More on a proposal explaining the opportunity. Since then, inspired by great conversations at the 2013 Mozilla Summit, Mozillians have discussed and converged on a few foundational definitions that will inform our subsequent conversations about contributors. Simultaneously, the proposal (which has been in Google Documents until now) has slowly made its way around the organization by way of document invites.

Since there seems to be some interest in it, and since invite-only isn’t really the Mozilla way, I’m sharing the most recent version of the proposal here.

Please note: This is a proposal, it’s not a plan. If you support it, your advocacy will help! If not, your challenging questions will help, too!

Contributor Tools Program

Definition and Scope

The Contributor Tools program builds and maintains systems that connect contributors to contribution opportunities and helps keep them actively involved. These systems serve the entire project and are not specific to a given functional area or product. This includes tools that:

  • Offer people both online and offline ways to get involved with the project (such as a call-to-action on http://www.mozilla.org or an organization-wide events system)
  • Match new contributors with tasks and teams appropriate to their skills and interests (such as a task board or a tool to help contributors find bugs)
  • Provide visibility into the activities contributors are involved in (such as a contribution logger or a dashboard)
  • Recognize people for their contribution to the project (such as a badging system or a profile management system)

This does not include tools that:

  • Serve the needs of just one functional area (such as a localization workflow tool)
  • Serve as a platform for interacting with an audience other than new and active contributors (such as a product site, a blog aggregator or an affiliate marketing program)
  • Would be required by Mozilla even in the absence of a vibrant contributor community (such as a bug tracker or a customer support website)

Problems Addressed

Connecting with and relating to contributors is an effort that enjoys broad support across Mozilla. But the tools we currently depend on to connect with and relate to Mozilla’s contributors are fragmented. As a result:

  • We do not undertake tools efforts according to a unified strategy
  • We do not measure the value or impact of these efforts in any comprehensive way
  • We do not take advantage of the efficiencies or provide the cohesive experiences that shared technologies, data, processes and resources could deliver

The Contributor Tools program will address these problems by unifying various tools efforts in a single program, creating a new structure for strategy, measurement and performance.

Stakeholders

The stakeholders for these tools include the staff and volunteers actively involved with building communities around their projects and the contributors who devote effort to furthering Mozilla’s mission. These stakeholders are represented by the Systems and Data Working Group of the Community Builders team.

The Systems and Data Working Group will meet regularly to establish decision-making structures for the program, set requirements for each system, create criteria of success for the program and advocate for and secure resources for those initiatives. In 2013 the group identified the systems required to complete Mozilla’s contributor tools suite.

Implementation

The Contributor Tools program should optimally have enough resources to maintain existing systems (providing security and stability fixes but few enhancements) while undertaking one major new effort at a time (such as building a new platform or redesigning an existing platform). This would require a small team of implementation staff plus the option to bring on contractors for burst efforts.

The Web Productions team has successfully built a program similar to the Contributor Tools program to deliver continuous service and improvement on http://www.mozilla.org. That program is accountable to a group of stakeholders from around the organization who are represented by a product owner. The product owner works closely with a program manager who helps guide the efforts of a cross-functional implementation team including some dedicated staff, some shared staff, some contractors and some contributors.

Implementing a similar approach for the Contributor Tools program would mean identifying individuals to occupy all of those roles. The exact number of individuals would depend on the scope of the program’s accountability. Our initial analysis suggests that existing staff and contractors might be able to provide most or all of the resources initially needed by this program.

Leverage

This program will also be able to gain additional leverage in two ways:

  1. Current community tools efforts are fragmented with teams building siloed functionality that could be extended to support the entire project (e.g. an events manager in reps.mozilla.org, contribution dashboards in support.mozilla.org). Numerous staff throughout the organization contribute, or are ready to contribute, to these fragmented efforts. Guiding their efforts with a unified strategy will allow for smarter allocation of existing resources.
  2. These tools will also serve as featured web development projects for new contributors. The program’s charter could include a mandate to maximize contributor involvement in system development.

Next Steps

The most minimal implementation of this program would require some realignment of product and engineering teams to cover the broader scope contemplated here:

  • Product teams would drive products forward based on the priorities of the Systems and Data Working Group of the Community Building team.
  • Implementation teams would shift between projects as necessary to achieve the program’s vision.

This realignment would enable the program to undertake Contributor Tools efforts according to the priorities established by a broad coalition of stakeholders.

A more ambitious program implementation might also include:

  • Adding a full-time Community Builder to the program team to maximize contributor involvement in product implementation.
  • Enlisting engineers, designers and other implementation experts from elsewhere within the organization who are already working on this effort.

These additions would enable the program to develop new features more rapidly and/or support more systems. Furthermore, the full-time Community Builder’s role could be charged with establishing a model for other web projects to use, thereby increasing project capacity across the entire organization.

Things Made In Times Past

I have a folder on my hard drive full of pictures and stories and songs I’ve made over the years. You might call them B-sides. I made most of them before self-publishing was so easy to do.

Most of these digital artifacts are just awful, not worth sharing at all, but some of them are mildly entertaining. However, practically nobody has ever seen them!

Well, I can fix that. Here is the first in a series of Things Made In Times Past. I present it here for your mild entertainment.


Jessicaaa

I was inspired and delighted by the blog Twitter: The Comic and thought I’d try my hand at it. I found a tweet that conjured up a series of images. I drew it in Adobe Illustrator.

sheboygan_scan

I submitted my drawing to the curator of Twitter: The Comic, but he wasn’t inclined to publish it. In addition to its glaring artistic flaws, it probably isn’t funny enough. It’s not a funny tweet, but it is remarkably evocative. In just a handful of words the tweet conveys an entire, haunting narrative. And the narrative is true: @sheboyganscan, the source of the tweet, is a running account of police scanner traffic in Sheboygan, Wisconsin. Where, apparently, this kind of thing happens: