On Sun, Jun 10, 2012 at 10:03 PM, Tim Starling tstarling@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