[Foundation-l] Why is the software out of reach of the community?

[Aryeh Gregor]

On Fri, Jan 9, 2009 at 5:00 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> Why are so few community-developed mediawiki extensions used by the
> Foundation?

Because there's approximately one person (Tim Starling) who reviews
such extensions in practice, and he has limited time.  There's
approximately one other person (Brion Vibber) who is qualified review
such extensions, although he hasn't for a long time that I can think
of, presumably because he's busy with other things.

> Why do developers have such priviledged access to the source code

So that they can actually improve it.  I don't know what alternative
you're suggesting.

> and the community such little input?

Because the community can't write code, or won't.  Features will not
get implemented unless someone writes the code.  Therefore, anyone who
cannot write the code themselves will not get their features
implemented unless they happen to convince someone with commit access.
 Anyone who writes reasonably good code and shows mild commitment to
the project is given commit access and becomes a developer if they so
choose.

> Why must the community 'vote' on extensions such as Semantic MediaWiki

The community is not being asked to vote on SMW that I've heard.  If
they don't show enough interest, however, it might not be worth the
time of one of the few possible extension reviewers to try reviewing
such a huge extension.

> and yet the developers can implement any feature they like, any way they
> like it?

No developer can implement any feature without review by Brion.  If a
developer were to commit a feature as large as SMW, it would be
disabled or reverted, for the same reason as given above: nobody with
time to review.  This has happened with a number of features at
various points, like category and image redirects/moves, and
rev_deleted.  They were all committed by developers but haven't been
enabled (or have by now, but weren't for a pretty long time).

> Why does the Foundation need 1 million for usability when amazing tools
> continue to be ignored and untested?

Part of that million will be spent on looking at existing tools.  The
resources for that currently don't exist, or anyway aren't allocated.

> Why has the Foundation gone ahead and approved the hire of several employees
> for usability design, when the community has had almost zero input into what
> that design should be?

We've received multiple assurances that all the usability improvements
will be made in a fully transparent fashion with community input, as
befits Wikimedia's mission.

> Why is this tool not being tested on Wikipedia, right now?
> http://wiki.ontoprise.com/ontoprisewiki/index.php/Image:Advanced_ontology_browser.gif

Because it hasn't met review for enabling on Wikipedia, and likely
won't without major structural changes (for performance reasons).
Wikimedia handles 70,000 requests per second peak on 400 servers or
so.  You cannot do that if you willy-nilly enable code that hasn't
been carefully tested in a suitably large production environment.  And
no non-Wikimedia wiki is anywhere close to the size of Wikipedia.

On Fri, Jan 9, 2009 at 5:33 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> 800,000 / 30,000 = 26. Is that not a fair wage?

I find it incredibly unlikely that you'd be able to find 26 developers
with enough skill who are willing to work for $30,000 a year average.
That's below entry level for programmers, let alone senior
programmers.  You certainly can't rely on current economic conditions,
unless you don't mind if they all jump ship as soon as the economy
improves and before they're properly familiar with the software.

Moreover, I'm pretty sure that a large chunk of the money is going to
have to go to conducting the actual usability tests.  I don't know how
expensive those are, but they can't be free.

> I would like to make clear that I believe the usability issue has largely
> been solved, and the community is just waiting for the core developers, who
> have kept a tight lock and key on the source code, to recognize that.

Can you propose any tenable alternative development model that
wouldn't overload the servers or crash the site when people upload
code that's buggy or just doesn't scale?  We have enough of that
checked in with our current procedures.  It's only kept at bay because
everything is reviewed by one of a few highly trusted people, who have
worked on MediaWiki and Wikimedia for several and are intimately
familiar with the details of how it works and what's been done before.

You cannot escape that review barrier.  Every open-source project has
it, and must have it, to avoid their code becoming a complete mess.

On Fri, Jan 9, 2009 at 6:13 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> I am skeptical of the current development process. That is because it has
> led to the current parser, which is not a proper parser at all, and includes
> horrifying syntax.

The current parser is inherited from somewhere between 2001 or 2003.
It's possibly even inherited from UseModWiki.  It was developed before
the current development process was in place, and so has nothing to do
with it.

On Fri, Jan 9, 2009 at 6:50 PM, George Herbert <george.herbert at gmail.com> wrote:
> It would be a potentially acceptable technical solution to change the parser
> and markup syntax to make it easier to work with, as long as there was an
> automated conversion tool to shift from what's in the DB now to what would
> be there going forwards.

Correct, but it would still be a huge project.  And there's only about
one person who would possibly be situated to do it right, and he has a
ton of other critical things to do.

On Fri, Jan 9, 2009 at 6:59 PM, Brian <Brian.Mingus at colorado.edu> wrote:
> I believe it my be the case
> that the often bizarre idiosyncrasies of MediaWiki were implemented because
> the developers were spread out around the world, in isolation, communicating
> only over IRC and sometimes e-mail. I know there are yearly developer spurts
> at Wikimania, but I do not know about the daily development environment at
> the offices, and whether development continues in a largely isolated
> fashion.

The large majority of new code is written by volunteers in their spare
time.  These volunteers are not going to be willing or able to move to
a centralized place to improve communication, and Wikimedia cannot
afford to drop them.  In any event, communication over IRC, e-mail,
and websites is the universal standard in the open source world, and
has resulted in a large number of unquestionably high-quality
products, like the Linux kernel and Firefox.

I don't know what you want -- more involvement of the community (which
is distributed across the world), or less communication by purely
electronic means?  You can't have both.