On Jan 16, 2015, at 11:27 AM, Ryan Lane rlane32@gmail.com wrote:
On Fri, Jan 16, 2015 at 4:29 AM, David Gerard dgerard@gmail.com wrote:
On 16 January 2015 at 07:38, Chad innocentkiller@gmail.com wrote:
These days I'm not convinced it's our job to support every possible scale of wiki install. There's several simpler and smaller wiki solutions for people who can't do more than FTP a few files to a folder.
In this case the problem is leaving users and their wiki content unsupported. Because they won't move while it "works", even as it becomes a Swiss cheese of security holes. Because their content is important to them.
This is the part of the mission that involves everyone else producing the sum of human knowledge. They used our software, if we're abandoning them then don't pretend there's a viable alternative for them. You know there isn't.
What you're forgetting is that WMF abandoned MediaWiki as an Open Source project quite a while ago (at least 2 years ago). There's a separate org that gets a grant from WMF to handle third party use, and it's funded just well enough to keep the lights on.
Take a look at the current state of MediaWiki on the internet. I'd be surprised if less than 99% of the MediaWiki wikis in existence are out of date. Most are probably running a version from years ago. The level of effort required to upgrade MediaWiki and its extensions that don't list compatibility with core versions is past the skill level of most people that use the software. Even places with a dedicated ops team find MediaWiki difficult to keep up to date. Hell, I find it difficult and I worked for WMF on the ops team and have been a MediaWiki dev since 1.3.
I don't think adding a couple more services is going to drastically alter the current situation.
- Ryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This sounds like a problem we need to fix, rather than making it worse. I'd most wikis are not up to date then we should work on making it easier to keep up to date, not making it harder. Any SOA approach is sadly DOA for any shared host; even if the user has shell access or other means of launching processes (so excluding almost every free host in existence here), there is no guarantee that a particular environment such as node.js or Python is installed or at the correct version (and similarly no guarantee for a host to install them for you). Such a move, while possibly ideal for the WMF, would indeed make running on shared hosting nearly if not entirely impossible. The net effect is that people will keep their existing MW installs at their current version or even install old versions of the software so they can look like Wikipedia or whatnot, rife with unpatched security vulnerabilities. I cannot fathom that the WMF would be ok with leaving third-party users in such a situation.
Moving advanced things into services may make sense, but it should not come at the expense of making the core worthless for third parties; sensible refactors could still be done on core while leaving it as pure PHP. Services, if implemented, should be entirely optional (as an example, Parsoid is not required to have a base working wiki. I would like to stick to that model for any future service as well).
Regards, Ryan Schmidt