This weekend I attended the Mentor Summit that winds up the Google Summer of Code. It’s an event where up to 2 mentors from each organization involved are invited to hang out at the GooglePlex for a weekend, mingle with folks from other open source projects and see what happens. We discussed all sorts of things related to the Summer of Code program, in addition to a variety of other, generally open-source topics. It was operated as an unconference, so we made up the majority of the schedule as we went, and modified it as required.
I was at BizTechDay on Friday afternoon at the WordPress table, after which Raanan was kind enough to drop me off down in Mountain View at the Wild Palms Hotel, where everyone was staying for the event. That night there was food provided and some drinks, general mingling/networking etc. The next morning we were all shuttled over to the GooglePlex (although I got a ride with the guys from TYPO3, thanks!) where we could grab breakfast, and up to the main room where we started the process of figuring out a schedule for the next day and a half. People suggested topics on large sheets of paper and each mentor had 8 stickers which were used to vote on sessions to indicate their relative popularity, and thus which room they should use.
Once sessions were decided, we scheduled them in on a giant grid which was provided, and then we could break out and start attending sessions which interested us. I tried to go to something in every time slot, and here are a few general notes from the 3 most interesting sessions I attended:
- WordPress has a relatively bad reputation for security, particularly amongst open source folks (who admittedly tend to have a more heavy-handed view of those sorts of things)
- A few people (specifically Jake Applebaum of Tor and Dan Collis-Puro of the Berkman Center for Internet & Society) thought that specifically doing security-only patches for WordPress, and doing them for “old” versions would be a way to increase the number of users who applied them
- Doing security-only patches would also potentially allow us to do fully-automated core updates.
- Getting designers involved in open source projects is really difficult
- Breaking down small, bite-sized projects is a better way to get designers involved (one small module, one form, *something*)
- Designers need to be involved from the ground up where possible. It helps build respect and trust, and it means they understand what they’re designing better, so they avoid coming across as “coming down from on high” with their opinions
- All the major CMSs (WordPress, Drupal, Joomla,TYPO3, even MediaWiki to an extent) are coalescing around some similar problems/approaches, and are generally becoming application “frameworks” with a “default mode”.
- There is a LOT of potential to pool/combine development skills across these platforms to build common, core libraries (for things like Open ID, OAuth, Feed parsing, etc) where it makes sense
- There’s a lot to be learned from each other, yet we all felt like there was a culture of not wanting to publicly acknowledge/interact with each other for some reason (everyone is a zealot?)
- Below is a photo of the board of notes from a discussion on why the number of women involved in open source projects is so low:
For more detailed notes on all sessions, you can visit the mentor summit wiki.
All in all it was a great event, and I met some really cool people who I hope to maintain some connection with over time. I’m also hoping that perhaps from this we can start some sort of cross-pollination of ideas (and maybe even code) between some of the popular CMSs where it makes sense, and perhaps implement the idea of security-only patches in WordPress. We’ll see what happens.
Back porting fixes and supporting older versions is is a really interesting idea. I would love to see some evidence based analysis of the costs and benefits.
Off hand I think it is generally really expensive. Particularly, with ~3 releases a year. It also encourages some of passive development community to sit on older versions.
The WordPress 2.0 Legacy branch was a good experiment, but recently retired earlier than planned:
http://wordpress.org/development/2009/07/the-word…
Having one supported version (+1 sometimes when new major version) is also most manageable for WordPress citizens.
Having said that was anyone:
* Providing details on how to do this effectively?
* Volunteering to take (some of) this on?
Backporting needs to be done by people for whom an itch is being scratched. As a commercial entity in Drupal land, I've done this in the past once a feature is in a "newer" version — backport it so it is available on an earlier version.
It's been my observation that in WP land, there are limited core maintainers, so it would definitely be "expensive" (time/effort/etc.) for them to do this. It's also easier to support backports when the components are a bit more modular.
Re: libraries. We've all been burned by insecure third party libraries, never mind licensing issues, hence the likely non cooperation. I agree there is a lot more here to be shared. Since PEAR seems all over the place in terms of quality, that might also be part of the distrust of common libraries in PHP. PEAR seems the likely place to do more work on this, though?
Definitely agree RE: the expensiveness of backports given the relatively small number of core maintainers, and that's why I assume it hasn't been done in the past.
For libraries, I think it's interesting to note that (as far as I'm aware) none of the CMSs mentioned in my post actually use PEAR. Don't know why that is necessarily, but I would hazard a guess that it's because they all try to avoid inter-dependencies as much as possible? The other main issue I could see is that WordPress is still PHP 4.3 compatible, which would preclude it from using most libraries which would be accepted into Drupal/Joomla, which are both moving on into PHP5-land.
Being "expensive" was my main thought against the idea, but I could also see the merits to people being able to rely on a specific version being "stable" and secure for "x" amount of time, especially if we're moving towards being more of a platform.
The discussed approach would be that we'd release a new version, and agree to maintain the security of that release for "x" time, let's say 1 year. Any security-specific issues discovered in the next year would be released as an automatic upgrade for users of that specific version (and be rolled into the current version obviously).
Dan Collis-Puro said he would be interested in at least helping out with managing the security releases/patches. The work he does at the Berkman Center requires him to be involved with a lot of different CMSs/platforms, and he runs a large WPMU install over there.