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.

Co-Authors Plus v2.6.3: Enhancements and bug fixes

Co-Authors Plus makes it easy to add multiple bylines to a given post, and has full support for custom post types. Out just a moment ago, v2.6.3 has the following improvements:

  • AJAX user search is back to searching against first name, last name, display name, email address and user ID. The method introduced in v2.6.2 didn’t scale well across hundreds of users.
  • French translation courtesy of Sylvain Bérubé.
  • Spanish translation courtesy of Alejandro Arcos.
  • Bug fix: Resolved incorrect caps check against user editing an already published post. Thanks to Doug in the WordPress.org forums for the help.

Please post any questions, bug reports, feature requests, etc. in the WordPress.org forums. If you want to contribute code, I’m eyeballing co-author management in Quick Edit and guest author functionality for v2.7.

For WordPress.com VIPs, this update has already been deployed to the shared plugins repo.

#techrakingcir: The Future of the CMS

Today, I’m down at Google in Mountain View at Techraking, a gathering of technologists and investigative journalists. It’s been super inspiring because of the fresh to me perspectives — I’d love to help Portland media outlets with projects like those I’ve heard about.

At lunch, I learnt I was to lead a small group breakout on “the future of the CMS.” To keep the discussion going, we started out by brainstorming the things we liked and want to improve our respective software, and then did a roundtable to identify our six month personal goals.

Some things people like about their CMS:

  • Drupal done well is easy to use; there are a ton of modules
  • Affordability, open source is cheap
  • Community to work with
  • Many different homepage templates to choose from depending on the stories of the day

What people would like to improve (lots of conversation, as expected):

  • Data portability
  • More headless; produce output other than HTML
  • Scalability, faster when many people are working in the admin
  • Less steps for completing common, simple tasks
  • Integration with story budgeting, calendaring; API for story flow
  • Magical WYSIWYG editor; auto-save that works; track changes
  • Support structured data / semantic markup
  • Customization for story layout
  • Small pieces loosely joined; better integration with other services

Given the short notice, I thought the breakout session went quite well. About twenty people showed up. In terms of what worked:

  • Small group discussion; knew enough backgrounds to call out different people to talk
  • Noted salient points on the whiteboard as a way of plotting direction
  • I enjoyed the “what are you going to work on in the next six months” takeaways at the end

Next time, we should:

  • Figure out the location ahead of time so we don’t waste time finding it
  • Have people introduce themselves if they haven’t spoken yet
  • Every fifteen minutes, have something for everyone to participate in so people don’t check out

Co-Authors Plus v2.6.2: Enhancements and bug fixes

Co-Authors Plus makes it easy to add multiple bylines to a given post, and has full support for custom post types. Out just a moment ago, v2.6.2 has the following improvements:

  • AJAX user search matches against first name, last name, and nickname fields too, in addition to display name, user login, and email address.
  • Comment moderation and approved notifications are properly sent to all co-authors with the correct capabilities.
  • Filter required capability for user to be returned in an AJAX search with ‘coauthors_edit_author_cap’. This defaults to ‘edit_posts’
  • Filter out administrators and other non-authors from AJAX search with ‘coauthors_edit_ignored_authors’
  • Automatically adds co-authors to Edit Flow’s story budget and calendar views.
  • Bug fix: Don’t set post_author value to current user when quick editing a post. This doesn’t appear in the UI anywhere, but added the post to the current user’s list of posts. See related forum conversation.
  • Bug fix: Properly cc other co-authors on new comment email notifications
  • Bug fix: If a user has already been added as an author to a post, don’t show them in the AJAX search again.
  • Bug fix: Allow output constants to be defined in a theme’s functions.php file and include filters you can use instead.

Please post any questions, bug reports, feature requests, etc. in the WordPress.org forums. If you want to contribute code, I’m eyeballing co-author management in Quick Edit and guest author functionality for v2.7.

For WordPress.com VIPs, this update has already been deployed to the shared plugins repo.

Quote

I worry about the independent web. I worry about the content creators, and I worry that if 100 percent of the distribution of everything starts to go through just a few websites, that kills the vibrancy.

A few years ago, Google started favoring some of their own websites over others. They left a path of scorched earth through many prominent businesses and publishers. Facebook hasn’t done that, but they could. And I think that would be bad for the web as a whole.

As things like Facebook’s news feed become ever more ingrained in our lives, the knobs they turn are hugely influential. For a year now, I’ve said scripting is the new literacy. That’s something I strongly believe. In Douglas Rushkoff’s latest book, he talks about “program or be programmed.” That is, if you’re not in control of your inputs, you’re not really in control of your outputs either. You’re just a reactionary force.

[...]

The Internet needs a strong, independent platform for those of us who don’t want to be at the mercy of someone else’s domain. I like to think that if we didn’t create WordPress something else that looks a lot like it would exist. I think Open Source is kind of like our Bill of Rights. It’s our Constitution. If we’re not true to that, nothing else matters.

Matt Mullenweg — Open Web FTW

Co-Authors Plus v2.6: Search user’s display names, change byline order and more

Co-Authors Plus makes it easy to add multiple bylines to a given post, and has full support for custom post types. Out this evening, v2.6 has the following improvements:

  • Sortable authors — drag and drop the order of the authors as you’d like them to appear
  • Search for authors by display name so you can easily add bylines by first or last name
  • Option to remove the first author when there are two or more listed
  • More reliably generates the published post count for each user

Thanks to those in the forum who provided feedback and special thanks to Russell Heimlich for his contributions with sortable authors. If you feel like giving back, there are a few tickets open we’d love patches for. In particular, guest bylines would be pretty neat. I have a possible direction you can go if you’re looking for inspiration.

For our WordPress.com VIPs, this release will be available in the shared plugins directory in just a moment.