Architecting the future of MediaWiki: This week we're interviewing Brion Vibber about the then-upcoming Architecture Summit. Brion is a long time Wikipedian, the first employee of the Wikimedia Foundation, and currently the lead software architect working with the mobile team.
This week we're interviewing Brion Vibber about the then-upcoming Architecture Summit. Brion is a long time Wikipedian, the first employee of the Wikimedia Foundation, and currently the lead software architect working with the mobile team.
What do you hope to get out of the Architecture Summit?
I hope to get a better sense of community involvement in moving things forward in the MediaWiki world. We've done a lot of ad-hoc discussions in small groups but we don't have a good "big picture"—I'm hoping this and future Arch Summits can help us get that: get people involved in the core, make sure multiple voices are heard, and get us to really rally around potentially big changes that are going to take a lot of work to do.
Are there any requests for comment or topics you're especially looking forward to discussing and implementing?
Service-oriented architecture interests me greatly—we're breaking more and more pieces out into services like search engine, parsing, image scaling; and with experiments like mobile apps we're even changing out the front end in some areas. Potentially, more pieces that fit together and can be maintained separately could be a big change in how we work.
What do you view your role as an architect as?
It's a vague and mysterious term which no one understands. :) But seriously, as a longtime contributor with lots of fingers in the pudding, as one might say, I can provide historical perspective and, hopefully, can help say "that's a good idea" and "that's a bad idea"!
Recently, there have been discussions about Wikimedia's needs versus the needs of other MediaWiki users in terms of software development, and now the MediaWiki release process has been contracted out to a third-party. Do these differences affect your decisions as an architect?
It's definitely interesting—when software that used to be done by a tiny group gets used more and more, it takes on a life of its own. I think that's a great thing, and having more input from third-party users is only going to help us make a stronger more flexible product.
You've said that a push is being made for a MediaWiki 2.0. Code aside, what do you think some of the biggest difficulties will be in working towards that goal?
We're going to have to have some large projects that take time and are controversial with users—look at the VisualEditor project with its associated Parsoid backend for a living example, and the discussions currently going on around video (especially MP4) and discussion systems (Flow etc). These are going to be Hard because we have to "sell" them to a user community which consistent of multiple constituencies, some of which are loud and make themselves heard and some of which are silent. Of course other things like improving the search engine are almost invisible, but just as much work on the backend!
I think we're going to reach 2.0 piece by piece, by reforming and refactoring and adding new abilities, and perhaps trimming off some of the old.
Many Wikimedia communities felt that the Foundation was not receptive enough to feedback during the VisualEditor deployment. As a longtime community member and MediaWiki developer, what is your take on the situation?
We're definitely still learning how to handle these situations... Visual Editor is one of our "moonshot" projects that's very important, and the trade-off between making it available for real testing and keeping it out of the way of people who have established workflows—or don't want to deal with the intermediate bugs—is ... a learning experience.
It's been a little over a year since your last interview with the Signpost. Anything interesting and exciting that you've worked on since then that you'd like to share?
I've done a lot of work on mobile apps which excites me; we can do more system integration than we can do with a plain web site—but that might change in the future! The web gains a lot of abilities over time, and I'll be excited to see the day when we really can ignore "native apps" on any platform.
It's also just a good litmus test for reusing and re-presenting content—and for figuring out how to integrate a community workflow into a separate tool. There've been editing helper tools for desktop for a long time but they've always been niche. The apps need to be able to represent the common reader *and* the power user, and it's an interesting set of tradeoffs.
In brief
Not all fixes may have gone live to WMF sites at the time of writing; some may not be scheduled to go live for several weeks. Content incorporated from Tech News.
Deployment freeze: With the combination of a US holiday on Monday and the Architecture Summit, there will be no major deployments this week. (announcement)
Special:ActiveUsers disabled: Due to performance issues, the special page has been disabled on all Wikimedia wikis. (code change)
No modules requested: The text users see when directly visiting load.php has been improved. Developers are still unsure who "Max" is. (code change)
The JavaScript that supports playing videos will now be loaded differently. If you notice videos that go directly to the file when clicked, please file a bug or report it to Bawolff. (bug 55550)
Engineering report published: The December 2013 report covering the Wikimedia Foundation's engineering activities has been published onwiki (blog version), and in summary form.
ULS disabled: Due to performance issues, the UniversalLanguageSelector extension was temporarily disabled. Users can opt-in to it by enabling it in their preferences. (bug 56433)
Twitter
LinkedIn
Reddit
Digg
+ Add a comment
Discuss this story