Will Norris
willnorris.com

Hi, I'm Will Norris. You can find me online at willnorris.com.

I'm an engineer in Google's Open Source Programs Office, where we provide technical and policy infrastructure for Google's various open source efforts. We help ensure that Google complies with the licenses of the open source software we use internally, help Googlers release their code as open source, and support the broader open source community through events like the Google Summer of Code.

Outside of work, I love to hack on WordPress, mainly for my own use and enjoyment, but I also maintain a handful of plugins.

But before we really look at how to contribute, I'd like to talk a little about why I contribute.

Why contribute to WordPress

b2 / cafelog

…contributing to open source, and particularly the WordPress project, is probably one of the best learning opportunities on the Internet.

Sharecropping is a system of agriculture in which a landowner allows a tenant to use the land in return for a share of the crops produced on the land. The sharecroppers didn't own the land they lived and worked on, and in most cases didn't own the equipment they worked with. They received their wage and nothing more, with no real opportunity to advance.

Most of today's popular services are a modern-day equivalent to sharecropping with data. Users are allowed to use the service at little or no cost, but often have limited ownership of their own contributions, are subject to the policies and terms of service for the site, and almost never have control of how their content is accessed (specifically, the URL for the content uses a domain name owned by the service).

What happens when the service decides that your content violates their community guidelines? (Blogger and Tumblr are both changing their policies surrounding adult content)
Or that your chosen name doesn't meet their name policies? (Facebook and Google+ have so-called "real name" or "common name" policies that have caused problems for users with non-traditional names)
Or what happens when a large company decides they really want your chosen username, and the site is willing to give it to them? (This has happened with both Twitter and Tumblr, among others)

What happens to your data then? Many services now let your export your data in some format, but what about the URLs? In most cases, you'll never be able to redirect those to wherever you decide to move your data.

Despite the issues around data ownership and control, these types of services are flourishing, and for very good reason. They work really, really well. And their user experience is really good, particularly on mobile.

Instagram - provides an incredibly simple interface for taking pictures, applying some basic filters, and then sharing them with friends.
Google+ - one of the first a applications to auto-upload your photos, also with a great UI for composing and sharing content
Pinterest - while primarily thought of as a content curation service for images discovered on the web, they also have a great mobile experience for browsing pinboards.
Facebook Home - even if you don't really like the idea of a Facebook powered home screen, it's hard to deny that the application looks great. Chat heads in particular have received a great response, even from folks critical of the rest of the app.
Vine - Vine did for video what Instagram originally did for photos, making it very simple to create and share simple videos.
Path - one of the first successful social networks to launch with a mobile-only strategy, they certainly set the bar for mobile social apps

These are some of the best mobile experiences in the industry, but they all feed into data silos and sharecropped accounts. Now I don't fundamentally have a problem with these services. In fact, I've found myself consuming and sharing content on mobile a lot more recently. But I really would like to maintain more ownership of my data and have control over how it is accessed.

While I don't personally use my phone or tablet for long-form blogging, why shouldn't the mobile experience for sharing content on my own WordPress site, where I do have complete control and ownership of the data, just as good as these other services? Programmers often talk about making the "right way" to do something also be the easiest way. Shouldn't that principal apply here as well?

IndieWebCamp

Of course, I'm not the only one who cares deeply about owning my own data.

IndieWebCamp is an annual event in Portland, Oregon timed to be the weekend following Open Source Bridge; we just had the third IndieWebCamp last month.

The indie web itself is actually a really simple concept... it's about owning your identity and your content online. It starts by owning a domain name, and using the domain to publish your content.

It's important to note that the indie web is not about eschewing the silos altogether. That's actually where many previous, similar efforts have failed. The goal here is to leverage these larger services for the social connection they provide, but to participate on them in a way that puts you in more control.

IndieWebCamp

POSSE - Publish (on your) Own Site, Syndicate Elsewhere

PESOS - Publish Elsewhere, Syndicate (to your) Own Site

Self-dogfooding - "Is its creator living and breathing it in his day-to-day online life? If so, awesome, if not, yawn." — Tantek Çelik

Publishing content can happen in two different ways.

The preferred model is one where you initially publish to your own site, and then syndicate elsewhere. This frees you from the arbitrary constrains of any one network, such as Twitter's character limit. When you syndicate out to these networks, you provide a link back to your original, full fidelity content.

The second model is one where you initially publish elsewhere, and then syndicate back to your own site. This ensures that you still have copy of your data, but puts you at the mercy of the site you are publishing to.

Finally, the indie web puts a strong emphasis on the notion of self-dogfooding. The idea of dogfooding, or using one's own product, is relatively common in tech companies. Self-dogfooding takes that one step further, and applies it to your personal day-to-day life (not just your day job). We've discovered that this results in many cases, this results in better results in less time because the creators is actually buliding it for themselves.

Start where you are
Use what you have
Do what you can

HTTPS

In December of 2012 I decided, partly out of principal and partly just as an experiment, to require all traffic on my personal site to happen over a secure HTTPS connection.

Due to where my site was being hosted at the time, I used a feature known as Server Name Indication. Typically, a server must have a unique IP address for each secure website it hosts, making it expensive, if not impossible, to host a secure site on a typical shared hosting plan. SNI allows multiple secure sites to be served from a single IP address, significantly lowering the barrier to entry. Browser support for SNI is good with the latest version of IE, and the last several versions of other major browsers. Support in various HTTP libraries is spotty at best.

Android ships with two HTTP clients, the Apache HTTP Client and Android's implementation of HttpURLConnection. Older versions of Android work better with the Apache client, however it doesn't support SNI. For more recent versions of Android, HttpURLConnection is recommended. At the time, WordPress for Android used the Apache client which wouldn't work with my site.

Now to be fair, it doesn't really surprise me that this hadn't been noticed before. I only ran into it because I was using the WordPress for Android app, AND I have SSL enabled for my site, AND I am using SSL with SNI. I don't imagine that there are a very large number of people who meet this criteria, so the number of effected users is probably pretty low. But for me, this was an absolutely critical problem, since it prevented me from using the app at all.

Every good work of software starts by scratching a developer's personal itch.

Understanding why you want to contribute often leads naturally to how you ought to contribute.

I've discovered that whatever the reason for why you want to contribute will often lead you to how you ought to contribute. And I've found that some of the best contributors to open source projects are those who have a specific pursuit in mind, a goal they are trying to accomplish.

Matt had the specific goal of ensuring that he would have a blogging platform to continue using. For me, I first just wanted to get the Android app working with my website.

As a newcomer to a project, a prerequisite for contributing to a project is first understanding it. This is a really important role, because so often the getting started process doesn't get documented as well as it could.

But as a secondary motivation, I wanted to have a great experience for publishing content to my own site from my phone, rather than feeling drawn to publish content into data silos.

Not getting paid to work on your passion project can often be more fun.

So often, when you're getting paid to work on a project or codebase, you tend not to have as much freedom to work on the parts you really want to. You have to work on what the client really wants, or the highest priority bugs. Not that there's anything wrong with that, those are important and of course need to get done. But I've found that when it comes to the projects I really love and work on for fun, getting paid to work on them can take the fun out of it.

When I started contributing to WordPress for Android, the core team was focused on other features that weren't as interesting to me at the time. But I was still able to work on the features that were important to me, as long as I got buy-in from the core team.

We're the lucky set of people with the skill and opportunity to make the changes we believe in. So we should.

This quote was part of an internal Google+ post discussing feature requests and bug reports between different teams at Google. Google's code base is sort of setup like a giant open source project. With only a handful of exceptions, every engineer at Google has the ability to view just about any line of code for any product. Because of this, it is very easy for an engineer to send a patch to another team to fix a bug or add a new feature. More importantly, this mode of contributing to other projects around the company is very much a part of the culture at Google. Googlers are empowered and encouraged (expected, even) to push for changes they believe in.

Thank You!

Will Norris
willnorris.com