On Sun, Jun 10, 2012 at 10:03 PM, Tim Starling <tstarling(a)wikimedia.org> wrote:
On 09/06/12 09:46, Rob Lanphier wrote:
I've long mused out loud about this
possibility, but I've become less
certain over time that this is a good outcome based on what happened
with Mozilla Messaging (spun out to work on Thunderbird, then folded
back into Mozilla). The overhead of yet another organization wasn't
worth it for them, and probably won't be worth it for us.
The two organisations would have to compete for senior staff, instead
of the time allocation being internally managed. I'm not sure who
would win.
The competition would be a fine thing. That's not the issue. It's
the challenge of making sure the separate organization has the
administrative ability to compete for the talent, which is a lot of
overhead to set up.
We could do better than how we're doing now, if
the WMF executive
recognised it as something we can legitimately spend time on.
Actually, I believe WMF executives (depending on which ones you're
referring to) think that some investment in this area is perfectly
reasonable. Many of the tradeoff decisions you may be frustrated with
are quite likely ones I've made personally (implicitly or explicity),
so let's not focus on the unnamed powers-that-be.
What level of investment do you believe we should be putting in here?
We're still planning to actually publish the tarballs and issue
security releases. We might even get in there and fix some installer
bugs as the crop up.
Sure, there's all types of work that would make MediaWiki for third
parties great:
* Making it so that Linux distro installs are great out of the box
* Distro-native packages are created automatically for all extensions
* Web-based installation and upgrading of extensions ala Wordpress
* Much smarter default install/configuration of MediaWiki+essential extensions
However, even assuming we agree these are the most obvious things to
work on (I suspect your list is different) we're far more likely to
find motivated volunteers to make this all happen than we are to put a
sustained effort on this stuff ourselves.
There are many things that benefit us *and* third parties:
* Visual editor
* Configuration database (i.e. make $wg* die in a fire) - slated for next year
* Lua
* Mobile support in MediaWiki core
I'm pretty sure that for every third-party-only feature idea we could
come up with has a pretty compelling "benefit everyone" counterpart.
Just because a
separate standalone MediaWiki entity isn't necessarily
viable, that doesn't mean that we can't figure out how to make the
release process a little more community-driven, so I'm glad there
seems to be momentum around outside contributors participating more
actively here.
The problem with community involvement is that the community is
continually undermined by the WMF, which hires all the best volunteer
developers and assigns them to work on things that benefit the
Wikimedia wikis.
Unlike most for-profit ventures, we're not planning to expand
indefinitely. Even if we did, reality would likely intervene to keep
us from getting very far.
So, this is, at worst, mostlya temporary problem. Moreover, is it
that much of a problem? It's not like those people are being forced
to work here. "Careful, don't volunteer to develop on MediaWiki, or
you might find yourself with a JOB that you get PAID for." :-)
Many of the volunteers that we hire were already working on
Wikimedia-specific stuff. I know there are plenty of cases where
volunteers have been working on third-party-specific features that
we've hired, but it's not clear they would have had the time/energy to
continue at the pace that they were sans a job from us (especially
those that started as volunteers while going to school).
Doesn't the WMF have a responsibility to
contribute back to the
community from which it draws so much code and talent?
If we had a private fork of the code, I'd accept this as a criticism.
We publish the source code, and I think we're generally pretty good at
being mindful about how the software will work for third parties.
This also gets back to the structural problem I've referred to. Given
the choice between:
a. Something that benefits Wikimedia sites, but not third party sites
b. Something that benefits Wikimedia sites and third-party sites
c. Something that benefits third-party sites, but not Wikimedia sites
...we're frequently going to shoot for "b", sometimes only achieve
"a", and rarely even aim for "c". It's just the nature of how
we're
set up, and it's also not smart for us to throw a lot of resources at
"c". We have so much to do in category "b" alone to keep us busy for
a very long time.
We do put some work into category "c", and we're not planning to pull
back from that. My point is that this is an area that is very well
suited to outside/volunteer work, since after all, outsiders will be
far more motivated to do a great job than we will.
Rob