How you might "open source (almost) everything"

I’d like to identify ways in which Automattic can release more code as open source by default.

In the WordPress.com repository, there’s a fair amount of code in use that’s never seen the light of day. Bits and pieces of this code would probably be useful to other people, and subsequently be improved as more developers read, implemented, and found new uses for it.

Open source is a unique and tremendously important phenomenon because it enables people to create more economic value than they could with previous collaborative frameworks. It’s “one of the most important ideas of our generation.” Automattic as a company believes this too; on the first page of our internal company documentation, Matt Mullenweg says, “I’m fine with releasing basically any code on WordPress.com that isn’t our password files.”

However, we don’t release as much code as we could be releasing, nor do we go about many our projects in the open source way we admire. I get the sense others in the community may agree.

Part of the challenge, as I perceive it, is that we (Automattic) build new functionality for WordPress.com, are lazy in our implementation, and it then becomes extra work at the end to “release” the functionality as a plugin. People have limited time in the day, understandably, and the last step doesn’t get done.

Last month, I wrote an internal blog post identifying four ways I’d like to see Automattic improve:

• Releasing (or mirroring) as much of the WordPress.com codebase as possible.
• Building community around parts of WordPress.com infrastructure, both in terms of people who use it and people who develop for it.
• Incorporating more third-party code into our codebase, and actively contribute back to it.
• Modeling best practices for open source projects, including support and documentation.

There was good conversation in the comments and, in somewhat typical fashion, not a lot of clarity on the takeaways.

Personally, I’d like to get as much WordPress.com code into a repository that VIP developers can check out and use in their development environments. Hell, it even means they can submit patches for fixes, coincidentally as Erick Hitter just did while I’m writing this post. I’d like to move our existing, private shared plugins repository into a WordPress.com public plugins repository which would also contain code like the shortcodes we’ve implemented on WordPress.com.

Communication is the lifeblood to open source, and the only remedy to poor communication is over-communication. For an open source project, discussion should be public, ticketing should be public, and the changelog should be public. This obviously isn’t to say that everyone should have an equal voice — rather, everyone should have an equal opportunity to participate. Making public WordPress.com’s internal code would be a start, but that would just be the start.

What other approaches do you think we could take?

If you haven’t already, I’d highly encourage you to read Tom Preston-Warner’s “Open Source (Almost) Everything”. It’s legit.