On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier robla@wikimedia.org wrote:
So: forks welcome! Any takers?
I would love to fork MediaWiki. Only problem: I'm employed by the WMF. That would make it a "captive fork" and not actually useful from the "MediaWiki Foundation" standpoint.
However, I've *also* got far too many projects on my plate already, so instead I'll briefly outline what my "dream fork" would look like, in the hopes that someone else will take this ball and run with it:
Goal #1: 100% compatibility with existing MediaWiki content. This doesn't (necessarily) mean that the databases need to be the same, or even that it needs to use wikitext, just that it has good conversion tools "on day 1".
Anti-goal #1: 100% compatibility with MediaWiki *features*. That is, the MW core codebase has accumulated a lot of cruft over time. It shouldn't be a goal to support *every* possible database backend, special page, or extension supported by MediaWiki, in fact *not* doing so is exactly why the fork is needed (the WMF has its hands tied by trying to make every possible user base happy).
For existing MediaWiki users to migrate this fork, it needs dead-simple conversion from existing MediaWiki installations (that's goal #1) but it also needs some compelling new features. This is actually the easy part, I think -- WMF is quite tightly constrained by the existing MediaWiki UX, so there are lots of ideas floating around out there on how to improve things on the frontend. There's also quite a lot of enthusiasm for (say) "github-style" content storage on the backend. Either one of those things (or a dozen others) could provide compelling reasons for users to switch. "Just a fresh look" could be enough.
The WMF is tightly constrained in ways that a potential fork would not be; not least by our focus on "Encyclopedic" content. Prior to employment by the WMF I worked with MediaWiki for internal documentation within a number of different technology organizations (heck, WMF itself uses MW this way on wikitech.wikimedia.org and mediawiki.org) and in most of those contexts a much more code-focused/version control centric/"markdown"-looking (ie, easy ways to write <code> blocks) UX would be compelling. This is a great opportunity to make some changes that the WMF can't/won't make in order to fit a non-encyclopedic need. (Not to mention non-text media, etc. There are products to create libraries on in-house 2d/3d artistic content, used for games, films, and graphic design; the present MW is almost entirely unsuited to this.)
Now, for the WMF to eventually migrate to this fork, it would need to *eventually* be capable of doing all the things the WMF uses MW for in the Wikipedia projects and others. But I'd urge any prospective forkers to think *long term* about this. Trying to do all WMF things on day one is probably not the best way to make your fork compelling for some group of users, and you'll need the support of that group of users in order to grow and maintain your fork. Let the WMF worry about migration and compatibility when it comes to it. Concentrate first on building something great. --scott
ps. Here's a grab bag of further fork ideas. None of these are *necessary*, of course, and some of them in fact may be *unwise*. But maybe these will stir the soul and trigger the coding fingers of someone out there:
* Parsoid provides an excellent substrate for translating existing wikitext into <something better>, whatever you choose that to be. Parsoid's motto: "we deal with wikitext, so you don't have to". We also have good ContentHandler abstractions in core so that you could treat wikitext as a "legacy format" in your fork, and use "something better" by default. (Markdown is popular with the kids, and there are lots of popular templating systems these days.)
* Forking MediaWiki means that you can use all the latest PHP features, right off the bat. Or else ditch PHP entirely! It's up to you. Maybe use ES2015 JavaScript. I do suggest sticking to one of the "major" languages if you wish your fork to have legs... although I'd love to see what an OCaml-native MediaWiki would look like. (Or you could code in a hybrid system, like https://phabricator.wikimedia.org/T114457 , and try to have the best of multiple worlds.)
* You can change the implementation language but keep the database schema. Or do the opposite. Lots of ways to avoid reinventing the entire wheel.
* MediaWiki is multilingual in theory, but in practice i18n features haven't gotten a lot of love in the past decade. What would a MediaWiki built around modern machine translation (and spell/grammar correction) look like? We tend to build these features around "big data" these days, and WP is quite a "big data" source.
* I'd love to see more real-time and social features integrated from the start. But you should probably keep in mind what it takes to create a safe community as well. Too many "clean sheet" redesigns foster harassment inadvertently by omission.
* When in doubt, steal! There are undoubtedly lots of other bits of code you can steal; there's no reason MediaWiki needs to do quite as many bespoke things as it does. Maybe if you weld together a slack clone, gitlab, and Parsoid you could get all messaging, backend storage, and wikitext rendering "for free". (See https://phabricator.wikimedia.org/T105175 for more "easy front end" ideas.) Mashing big pieces together might be the best way to build something compelling quickly (and keep the core code you have to maintain small).