Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> it's not like they don't have the resources to do it.

Have you ever looked at the Mediawiki code base? Last time I skimmed a bit, a few years ago, it was an utterly horrible mess of spaghetti PHP. Just finding developers capable of doing this would be a big challenge. The Wikimedia Foundation has a lot less resources than you might imagine, considering the reach of its projects, and there are an awful lot of other funding priorities (not to mention other code priorities). They’re doing the best they can, but making sweeping changes to the code base is a lot harder than it looks.

> I think there are powerful members of the community who want to keep it somewhat insular and closed off as a defense mechanism.

Do you have any evidence for that? As conspiracy theories go, this one seems pretty weak to me. I can’t think of another organization of comparable size which is as welcoming and open to involvement and contribution from ordinary community members, at all levels of decision making. Almost the entire management and operation of Wikipedia and the Wikimedia Foundation is carried out in public, nearly all of the parties involved are volunteers (with a quite small number of full time staff keeping infrastructure running, handling legal issues, and so on), and many many decisions are made collectively, by consensus.

It’s easy to hate on anything, as a disinterested outsider, without making any real attempt to understand the internal processes involved, but organizing millions of people is a highly non-trivial job, and I think the Wikimedia community has done pretty admirably, all things considered.



> Have you ever looked at the Mediawiki code base? Last time I skimmed a bit, a few years ago, it was an utterly horrible mess of spaghetti PHP.

That's basically the problem. They are devoting considerable resources to a GUI editor, and I believe have several paid staff, both programmers and UI/UX experts, dedicated to the project. But as step #1 it needed a rewrite of the horrible-mess-of-regexes parser into some kind of actual semantic parser, which due to the feature-creep of wikitext syntax (which looks nothing at all like a well-behaved programming language syntax) turned out not to be easy going.

They commissioned a full usability study in 2010: http://usability.wikimedia.org/wiki/Wikipedia_Usability_Init...

Here is some information on the parser-rewrite project: http://www.mediawiki.org/wiki/Parsoid

And on the visual-editor project: http://www.mediawiki.org/wiki/VisualEditor


I just downloaded Mediawiki and took a look at the source code. Some of the later added code doesn't seem as bad, but there's an overwhelmingly extreme amount of mingling between the data logic, including the classes and actions, and the html markup. It makes it utterly hard to read understand for someone wanting to contribute. The codebase isn't light either so (correct me if I'm wrong but) I don't think a complete rewrite of the application ever occurred after the first version.

Now if only some of us stopped creating social networks for kitties, and actually contributed our time and hackery into something that actually benefited the world.


You might be interested in the Parsoid project, which Wikimedia funded precisely to try to build a more maintainable pipeline for parsing syntax into some kind of AST or document model, disentangled from the other cruft: http://www.mediawiki.org/wiki/Parsoid

I believe it's currently being maintained separately, so the logic in MediaWiki itself is still the crufty version.


> Have you ever looked at the Mediawiki code base? Last time I skimmed a bit, a few years ago, it was an utterly horrible mess of spaghetti PHP. Just finding developers capable of doing this would be a big challenge. The Wikimedia Foundation has a lot less resources than you might imagine, considering the reach of its projects, and there are an awful lot of other funding priorities (not to mention other code priorities). They’re doing the best they can, but making sweeping changes to the code base is a lot harder than it looks.

If they lack the resources to do it, they could easily raise the money via a targeted donation drive or a kickstarter project. Telling the web: "Hey, here's what we want to do to make Wikipedia editing better, but we need $X to do it" would probably raise the target many times over. If they can't find good programmers right now, offer triple the salary or whatever. Incentives work.

> It’s easy to hate on anything, as a disinterested outsider, without making any real attempt to understand the internal processes involved, but organizing millions of people is a highly non-trivial job, and I think the Wikimedia community has done pretty admirably, all things considered.

How do you know whether I'm an insider or outsider?

I've contributed thousands of edits and was very active on Wikipedia maybe 6-7 years ago, but mostly stopped because of all the internal politics. Now I just fix typos or formatting errors when I notice them.

The fact is, if creating an easier way for newbies to contribute was a priority for the organization, I'm pretty sure they could have done it over the past many years. In that time whole companies were created from scratch. I can't believe that an organization as powerful (with such support and mindshare worldwide) as Wikipedia couldn't created a GUI editor. I could be wrong, but it just doesn't feel like they want it that much to happen, and the challenges in their way are used as excuses for not going full steam ahead...


"Just finding developers capable of doing this would be a big challenge."

I'm pretty sure one of the very highest profile websites on the entire internet could find developers capable of handling it.

Actually, I'm 100% certain of it.


Send them over. I’m sure the Wikimedia foundation would be glad to have them: http://wikimediafoundation.org/wiki/Job_openings

Edit: From the Wikimedia Foundation’s “2011–2012 Annual Plan”:

> 2011-12 Risks:

> 1) Editor decline is an intractable problem. Declining participation is by far the most serious problem facing the Wikimedia projects: the success of the projects is entirely dependent upon a thriving, healthy editing community. We are responding with a multi-faceted approach that blends big obvious fixes (e.g., Visual Editor) with more experimental approaches (e.g., the -1 to 100 retention projects and editor recruitment initiatives in India and Brazil). The WMF is also putting resources towards expanding community awareness and understanding of the problem, and putting in place mechanisms for decentralized community innovation so that community initiatives can help to solve it. We will be tracking progress throughout the year, and if necessary will sacrifice other activities to increase resources dedicated to this. [...]

> 9) A shortage of Silicon Valley technical talent hurts our ability to recruit and retain technical staff. The Bay Area is currently facing a major shortage of talented engineers, and tech companies are finding it difficult to hire and retain good tech staff. This could impair our ability to grow our tech staff as planned from 28 to 50. Mitigation: Like the rest of the tech sector, there is not much we can do to mitigate this serious problem. However, we will dedicate more resources towards technical recruitment in 2011-12 compared with 2010-11, and we'll be very clear about our value proposition: The Wikimedia Foundation is not about monetizing eyeballs, our direction isn't set by VCs, and we're financially stable. We offer a fair, friendly, fun environment for talented engineers who want their individual contribution to result in making the world a better place for hundreds of millions of people. [...]

> THE 2011-12 PLAN [...]

> Key activities supporting Priority #2, Diversifying the Editor Community are:

> 1) Visual Editor: A new default editing environment for Wikimedia projects which does not require markup. [...]

> 2011-12 Plan Targets [...]

> 5) Develop Visual Editor. First opt-in user-facing production usage by December 2011, and first small wiki default deployment by June 2012. [...]

> The 2011-12 plan reflects our continued desire to grow the organization's programmatic capacity by growing its staff, with an emphasis on thoughtful recruitment and integration of new people. In 2011-12, we plan to grow staff 50% from 78 to 117.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: