The future of shared hosting

classic Classic list List threaded Threaded
49 messages Options
123
Reply | Threaded
Open this post in threaded view
|

The future of shared hosting

Bryan Davis
There has been a lot of talk over the last year or so of how and when
to move MediaWiki to a service oriented architecture [0]. So much so
that it is actually one of the a marquee topics at the upcoming
Developer Summit.

I think the problem statement for the services RFC is dead on in
describing issues that MediaWiki and the Wikimedia Foundation face
today with the current monolithic MediaWiki implementation. We have
organic entanglements between subsystems that make reasoning about the
code base difficult. We have a growing need to API access to data and
computations that have historically been only presented via generated
HTML. We have cross-team and cross-project communication issues that
lead to siloed implementations and duplication of effort.

The solution to these issues proposed in the RFC is to create
independent services (eg Parsoid, RESTBase) to implement features that
were previously handled by the core MediaWiki application. Thus far
Parsoid is only required if a wiki wants to use VisualEditor. There
has been discussion however of it being required in some future
version of MediaWiki where HTML is the canonical representation of
articles {{citation needed}}. This particular future may or may not be
far off on the calendar, but there are other services that have been
proposed (storage service, REST content API) that are likely to appear
in production use at least for the Foundation projects within the next
year.

One of the bigger questions I have about the potential shift to
requiring services is the fate of shared hosting deployments of
MediaWiki. What will happen to the numerous MediaWiki installs on
shared hosting providers like 1and1, Dreamhost or GoDaddy when running
MediaWiki requires multiple node.js/java/hack/python stand alone
processes to function? Is the MediaWiki community making a conscious
decision to abandon these customers? If so should we start looking for
a suitable replacement that can be recommended and possibly develop
tools to easy the migration away from MediaWiki to another monolithic
wiki application? If not, how are we going to ensure that pure PHP
alternate implementations get equal testing and feature development if
they are not actively used on the Foundation's project wikis?


[0]: https://www.mediawiki.org/wiki/Requests_for_comment/Services_and_narrow_interfaces

Bryan
--
Bryan Davis              Wikimedia Foundation    <[hidden email]>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Max Semenik
On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis <[hidden email]> wrote:

>
> One of the bigger questions I have about the potential shift to
> requiring services is the fate of shared hosting deployments of
> MediaWiki. What will happen to the numerous MediaWiki installs on
> shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> MediaWiki requires multiple node.js/java/hack/python stand alone
> processes to function? Is the MediaWiki community making a conscious
> decision to abandon these customers? If so should we start looking for
> a suitable replacement that can be recommended and possibly develop
> tools to easy the migration away from MediaWiki to another monolithic
> wiki application? If not, how are we going to ensure that pure PHP
> alternate implementations get equal testing and feature development if
> they are not actively used on the Foundation's project wikis?
>
>
This is not even about shared hostings: it is pretty obvious that running a
bunch of heterogenous services is harder than just one PHP app, especially
if you don't have dedicated ops like we at WMF do. Therefore, the question
is: what will we gain and what will we lose by making MediaWiki unusable by
95% of its current user base?


--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Trevor Parscal-2
95% is pretty extreme.

I have always questioned the balance being struck here, and would welcome
an adjustment of the minimum requirements to run MediaWiki. In many cases,
if we can just require shell access we can automate away the complexity for
the typical use cases.

- Trevor

On Thu, Jan 15, 2015 at 10:49 PM, Max Semenik <[hidden email]> wrote:

> On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis <[hidden email]> wrote:
>
> >
> > One of the bigger questions I have about the potential shift to
> > requiring services is the fate of shared hosting deployments of
> > MediaWiki. What will happen to the numerous MediaWiki installs on
> > shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> > MediaWiki requires multiple node.js/java/hack/python stand alone
> > processes to function? Is the MediaWiki community making a conscious
> > decision to abandon these customers? If so should we start looking for
> > a suitable replacement that can be recommended and possibly develop
> > tools to easy the migration away from MediaWiki to another monolithic
> > wiki application? If not, how are we going to ensure that pure PHP
> > alternate implementations get equal testing and feature development if
> > they are not actively used on the Foundation's project wikis?
> >
> >
> This is not even about shared hostings: it is pretty obvious that running a
> bunch of heterogenous services is harder than just one PHP app, especially
> if you don't have dedicated ops like we at WMF do. Therefore, the question
> is: what will we gain and what will we lose by making MediaWiki unusable by
> 95% of its current user base?
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Brian Wolff
In reply to this post by Max Semenik
On Jan 16, 2015 2:49 AM, "Max Semenik" <[hidden email]> wrote:

>
> On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis <[hidden email]> wrote:
>
> >
> > One of the bigger questions I have about the potential shift to
> > requiring services is the fate of shared hosting deployments of
> > MediaWiki. What will happen to the numerous MediaWiki installs on
> > shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> > MediaWiki requires multiple node.js/java/hack/python stand alone
> > processes to function? Is the MediaWiki community making a conscious
> > decision to abandon these customers? If so should we start looking for
> > a suitable replacement that can be recommended and possibly develop
> > tools to easy the migration away from MediaWiki to another monolithic
> > wiki application? If not, how are we going to ensure that pure PHP
> > alternate implementations get equal testing and feature development if
> > they are not actively used on the Foundation's project wikis?
> >
> >
> This is not even about shared hostings: it is pretty obvious that running
a
> bunch of heterogenous services is harder than just one PHP app, especially
> if you don't have dedicated ops like we at WMF do. Therefore, the question
> is: what will we gain and what will we lose by making MediaWiki unusable
by
> 95% of its current user base?
>
>
> --
> Best regards,
> Max Semenik ([[User:MaxSem]])
>

Im quite concerned by this. Well shared hosting might be on the decline, I
still feel like most third part users dont have the competence to do much
more than ftp some files to their server and run the install script.

--bawolff
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Chad
On Thu Jan 15 2015 at 11:34:58 PM Brian Wolff <[hidden email]> wrote:

> On Jan 16, 2015 2:49 AM, "Max Semenik" <[hidden email]> wrote:
> >
> > On Thu, Jan 15, 2015 at 10:38 PM, Bryan Davis <[hidden email]>
> wrote:
> >
> > >
> > > One of the bigger questions I have about the potential shift to
> > > requiring services is the fate of shared hosting deployments of
> > > MediaWiki. What will happen to the numerous MediaWiki installs on
> > > shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> > > MediaWiki requires multiple node.js/java/hack/python stand alone
> > > processes to function? Is the MediaWiki community making a conscious
> > > decision to abandon these customers? If so should we start looking for
> > > a suitable replacement that can be recommended and possibly develop
> > > tools to easy the migration away from MediaWiki to another monolithic
> > > wiki application? If not, how are we going to ensure that pure PHP
> > > alternate implementations get equal testing and feature development if
> > > they are not actively used on the Foundation's project wikis?
> > >
> > >
> > This is not even about shared hostings: it is pretty obvious that running
> a
> > bunch of heterogenous services is harder than just one PHP app,
> especially
> > if you don't have dedicated ops like we at WMF do. Therefore, the
> question
> > is: what will we gain and what will we lose by making MediaWiki unusable
> by
> > 95% of its current user base?
> >
> >
> > --
> > Best regards,
> > Max Semenik ([[User:MaxSem]])
> >
>
> Im quite concerned by this. Well shared hosting might be on the decline, I
> still feel like most third part users dont have the competence to do much
> more than ftp some files to their server and run the install script.
>
>
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.

While I'm not entirely convinced about expanding the scope of MW's
dependencies just yet I am pretty convinced these days that "you need
shell access to something resembling a real server" is not an untenable
place to be in for our minimum requirements, especially as VPS prices
continue to fall.

-Chad
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Max Semenik
In reply to this post by Trevor Parscal-2
On Thu, Jan 15, 2015 at 11:27 PM, Trevor Parscal <[hidden email]>
wrote:

> 95% is pretty extreme.
>

Can't agree on this, as the number covers:

   - All curent shared host users
   - Those who use an entry-level VPS and would suddenly discover that with
   a few extra node services their RAM is insufficient
   - People who aren't technical enough to run a bunch of services glued
   together with PHP
      - Especially if these services are even a tiny bit more complex to
      install than `apt-get install`
   - People who run MW in strict corporate environments where installing
   just another piece of software is a big deal

I initially considered writing 99%, but decided that some users might
consider upgrading their plans, etc. Still, 99% is proably the accurate
estimate of current installations potentially affected by servicization.


> I have always questioned the balance being struck here, and would welcome
> an adjustment of the minimum requirements to run MediaWiki. In many cases,
> if we can just require shell access we can automate away the complexity for
> the typical use cases.
>

 Yep, maintaining the ability to run MW in crappy environments has always
been a losing battle, and especially since we're planning to ditch PHP 5.3
support soon (which would render MW incompatible with a lot of crappy
hosts) it might be the time to officially declare that we don't care about
supporting environments without shell access. Still, shell access does not
equate to root access or even to running Parsoid from userspace, that's a
different story.

--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Stas Malyshev
In reply to this post by Bryan Davis
Hi!

> One of the bigger questions I have about the potential shift to
> requiring services is the fate of shared hosting deployments of
> MediaWiki. What will happen to the numerous MediaWiki installs on
> shared hosting providers like 1and1, Dreamhost or GoDaddy when running
> MediaWiki requires multiple node.js/java/hack/python stand alone
> processes to function? Is the MediaWiki community making a conscious
> decision to abandon these customers? If so should we start looking for
> a suitable replacement that can be recommended and possibly develop
> tools to easy the migration away from MediaWiki to another monolithic
> wiki application? If not, how are we going to ensure that pure PHP
> alternate implementations get equal testing and feature development if
> they are not actively used on the Foundation's project wikis?

I think we're trying to fulfill a bit of a contradictory requirement
here - running on the same software both the site of the size of
*.wikipedia.org and a 1-visit-a-week-maybe $2/month shared hosting
install. I think it would be increasingly hard to be committed to both
equally. However, with clear API architecture we could maybe have
alternatives - i.e. be able to have the same service performed by a
superpowered cluster or by a PHP implementation on the URL on the same
host. Of course, the latter would have much worse performance and maybe
reduced feature set. How large is the delta we'd need to decide. But if
we have clear architecture I think it should be possible to define
minimum capability and have ability to degrade from full-power install
to reduced-capability install (e.g. - blazingly fast fulltext search or
just limited slow 'LIKE %word%' search?), while still keeping the same
architecture. Is this something we could do (or, having the API, let the
willing people from the community do it)? Is the $2/month use case
important enough to actually do it?

--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

S Page-3
In reply to this post by Bryan Davis
>
> One of the bigger questions I have about the potential shift to requiring
> services is the fate of shared hosting deployments of MediaWiki.
>

Seems like an opportunity. "Deploy your MediaWiki-Vagrant instance to our
cloud infrastructure cheap."  It's not $2/month, but Digital Ocean can host
a  1GB VM for $10/month. Maybe https://atlas.hashicorp.com/ will host
vagrant boxes cheaper.

Docker allows many Linux containers on the same physical system which
should lead to lower pricing. Some MediaWiki dockerfiles install Parsoid
and nodejs as well as MediaWiki and PHP, e.g. CannyComputing
<https://github.com/CannyComputing>/*frontend-mediawiki
<https://github.com/CannyComputing/frontend-mediawiki>* , or you'd have
separate container for each service. I can't figure out the pricing.

--
=S Page  WMF Tech writer
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

David Gerard-2
In reply to this post by Chad
On 16 January 2015 at 07:38, Chad <[hidden email]> 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.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Marc-Andre
In reply to this post by Max Semenik
On 15-01-16 02:48 AM, Max Semenik wrote:
> Can't agree on this, as the number covers [...]

An extra datapoint here:  I think I can reasonably consider myself an
atypical user at the tail end of the sysadmin curve, and yet the
principal reason why I had delayed installing VisualEditor on a
mediawiki I administer is Parsoid.

Not because it's unusually complicated to deploy and install - it's
about as trivial as possible under Ubuntu at least given that there is a
package - but because it changes a number of fundamental assumptions
about what a mediawiki install /is/ and what maintaining it involves.

Service-based has implications on reliability and security and - no
matter how well we manage those implications - they add moving parts and
complexities.  They increase the monitoring burden, and increase the
specialization and knowledge necessary to understand and debug issues.

I'm not saying any of those things are /bad/ or insurmountable, but that
they modify the landscape in a pretty drastic ways and that this /will/
impact the vast majority of users.

And I can honestly say that if the intent is to maintain a parallel
working implementation in pure php then - with my reuser hat - I don't
believe a word of it.  :-)  I happen to have been a long-time postgres
user, and yet when 1.23 rolled around and I wanted to start playing
around with VE I found that my only realistic alternative was to migrate
to mysql: postgres support had always been sporadic and not-quite-there
already, and the increased number of issues with the increased
complexity meant that it moved squarely in not-maintained-enough territory.

So yeah; there *is* a very significant impact.

-- Marc


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Mark A. Hershberger-4
In reply to this post by Trevor Parscal-2
Trevor Parscal <[hidden email]> writes:

> 95% is pretty extreme.

Not according to WikiApiary.  The largest host for wikis, even before
Wikimedia, is DreamHost followed closely by GoDaddy and other shared
hosters such as 1&1.[1]

Yes, Amazon and Linode are also near the top of the list, but from
experience, I can tell you that most of those aren't using anything but
PHP, and, if you're lucky, the Math and Scribunto extensions.

Even the most asked-for service of the SOA -- Parsoid for Visual Editor
-- is almost (but not quite) exclusively on WMF wikis.[2]

Developers within an organisation like the WMF don't have to worry about
what it takes to stand up and maintain a wiki -- they have Operations
for that.

Most people running wikis based on MediaWiki don't have a budget or a
staff exclusively for their wiki.  They don't have the resources or
knowledge to run a dedicated server.

There are things that can be done to address this -- make it easier to
set up a SOA-using wiki on your chosen virtual machine provider -- but
they need dedicated resources.

This probably means a really dedicated (group of) volunteer(s) or a new
focus on non-WMF use of MediaWiki by the WMF.  This seems to be the
direct result of the the decisions made by developers who've implemented
some very compelling features without (as Robla seemed to say recently)
any overall architectural direction.

Mark.



Footnotes:
[1]  https://wikiapiary.com/wiki/Host:Hosts

[2]  https://wikiapiary.com/wiki/Extension:VisualEditor

--
Mark A. Hershberger
NicheWork LLC
717-271-1084

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Brad Jorsch (Anomie)
In reply to this post by Stas Malyshev
On Fri, Jan 16, 2015 at 2:49 AM, Stas Malyshev <[hidden email]>
wrote:

> However, with clear API architecture we could maybe have
> alternatives - i.e. be able to have the same service performed by a
> superpowered cluster or by a PHP implementation on the URL on the same
> host.


The problem there is that the PHP implementation is likely to code-rot,
unless we create really good unit tests that actually run for it.

It would be less bad if the focus were on librarization and daemonization
(and improvement) of the existing PHP code so both methods could share a
majority of the code base, rather than rewriting things from scratch in an
entirely different language.

and maybe reduced feature set.


That becomes a hazard when other stuff starts to depend on the non-reduced
feature set.


--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Brian Wolff
On Jan 16, 2015 11:07 AM, "Brad Jorsch (Anomie)" <[hidden email]>
wrote:

>
> On Fri, Jan 16, 2015 at 2:49 AM, Stas Malyshev <[hidden email]>
> wrote:
>
> > However, with clear API architecture we could maybe have
> > alternatives - i.e. be able to have the same service performed by a
> > superpowered cluster or by a PHP implementation on the URL on the same
> > host.
>
>
> The problem there is that the PHP implementation is likely to code-rot,
> unless we create really good unit tests that actually run for it.
>
> It would be less bad if the focus were on librarization and daemonization
> (and improvement) of the existing PHP code so both methods could share a
> majority of the code base, rather than rewriting things from scratch in an
> entirely different language.
>
> and maybe reduced feature set.
>
>
> That becomes a hazard when other stuff starts to depend on the non-reduced
> feature set.
>
>
> --
> Brad Jorsch (Anomie)
> Software Engineer
> Wikimedia Foundation
>

I like this approach. After all it worked well enough for image
thumbnailing and job queue.

Writing things in different languages just reminds me of what a mess math
support used to be.

--bawolff
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Antoine Musso-3
In reply to this post by Bryan Davis
Le 16/01/2015 07:38, Bryan Davis a écrit :
> There has been a lot of talk over the last year or so of how and when
> to move MediaWiki to a service oriented architecture [0]. So much so
> that it is actually one of the a marquee topics at the upcoming
> Developer Summit.
<snip>

Hello,

Moving to a service oriented architecture will certainly ease Wikimedia
maintenance, or at least delegate maintenance authority to independent
sub teams which would be rather nice.

The monolithic approach of MediaWiki with all services / classes being
tightly coupled makes the platform rather hard to build upon.  It
certainly lacks clear contracts between components.


Can the SOA model be supported on shared hosts or by third parties?
Surely. But one has to handle the integration and release work to make
it easy to install all the components  and configure them.  Is Wikimedia
going to handle it? I doubt it.


The underlying choice is:

a) should Wikimedia keep being slowed down claiming MediaWiki is
suitable for others

b) Reclaims MediaWiki has a Wiki made to create and distribute free
knowledge geared toward supporting Wikipedia and others WMF projects.


I think WMF should reclaim it, take decisions and stop pretending we
support third parties installation.  That would mean going as far as
dropping postgreSQL support since we have no use for it.


So what we might end up with:

- Wikimedia using the SOA MediaWiki with split components maintained by
staff and the Wikimedia volunteers devs.  Code which is of no use for
the cluster is dropped which would surely ease maintainability.  We can
then reduce MediaWiki to a very thin middleware and eventually rewrite
whatever few code is left.


- The old MediaWiki PHP based is forked and given to the community to
maintain.  WMF is no more involved in it and the PHP-only project live
it's on life.  That project could be made to remove a lot of the rather
complicated code that suits mostly Wikimedia, making MediaWiki simpler
and easier to adjust for small installations.


So, is it time to fork both intent?  I think so.


--
Antoine "hashar" Musso


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

David Gerard-2
On 16 January 2015 at 16:09, Antoine Musso <[hidden email]> wrote:

> So what we might end up with:
> - Wikimedia using the SOA MediaWiki with split components maintained by
> staff and the Wikimedia volunteers devs.  Code which is of no use for
> the cluster is dropped which would surely ease maintainability.  We can
> then reduce MediaWiki to a very thin middleware and eventually rewrite
> whatever few code is left.
> - The old MediaWiki PHP based is forked and given to the community to
> maintain.  WMF is no more involved in it and the PHP-only project live
> it's on life.  That project could be made to remove a lot of the rather
> complicated code that suits mostly Wikimedia, making MediaWiki simpler
> and easier to adjust for small installations.
> So, is it time to fork both intent?  I think so.



This is not a great idea because it makes WMF wikis unforkable in
practical terms. The data is worthless without being able to run an
instance of the software. This will functionally proprietise all WMF
wikis, whatever the licence statement.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Subramanya Sastry
In reply to this post by Stas Malyshev
On 01/16/2015 01:49 AM, Stas Malyshev wrote:
> I think we're trying to fulfill a bit of a contradictory requirement
> here - running on the same software both the site of the size of
> *.wikipedia.org and a 1-visit-a-week-maybe $2/month shared hosting
> install. I think it would be increasingly hard to be committed to both
> equally.

This has always been my question independent of the specific choices
made or being made to address this. So, some answers could be:

* Yes, it is possible and for that we need to continue with a monolithic
install, and if VisualEditor/Flow, etc. is needed, then things like
Parsoid would have to become part of core so continue to support WMF's
product offerings.

* It is difficult to support installs equally well at the extremities of
scaling / performance requirements, and for WMF's scale and features
(new ones being developed and conceived on an ongoing basis), we need a
different architecture where there are independent services that can be
developed and maintained independently, but perhaps with packaging
solutions, a large subset of existing wiki installs can be supported and
developed

* It is not really possible to do both and there should be a fork /
split of the mediawiki codebase, and each should go their own way.

Maybe I am setting up strawmen to articulate my point of view, which is
the middle solution, simply because I don't believe that with continuing
demand / development of new features, you can make the same codebase
work for WMF's expanding feature set and for a lot of small wikis who
are content with simple wikitext-based wikis without any of the
additional complexity.

Anyway, independent of the specific outlines above, I think the question
that should inform a discussion would be: is it really possible for the
same codebase to support both WMF's requirements (I say WMF because it
is leading the development of new feaures / products) with new and
evolving products / features as well as the countless small wikis out
there who have exactly one ore two requirements of the wiki?

I am happy to be disabused of the importance of this question.

Subbu.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Greg Grossmeier-2
In reply to this post by David Gerard-2
<quote name="David Gerard" date="2015-01-16" time="16:27:22 +0000">
> This is not a great idea because it makes WMF wikis unforkable in
> practical terms. The data is worthless without being able to run an
> instance of the software. This will functionally proprietise all WMF
> wikis, whatever the licence statement.

"Unforkable" as a binary is not true. "Not easy to fork without
implementing all of the pieces carefully" is more accurate. But it's
still possible, especially since all of the config/puppet code that is
used to do it is open and Freely licensed.

It ain't easy hosting a site this large with this amount of traffic
(thanks Ops!) so it's not surprising that "forking" it wouldn't be easy
either.

--
| Greg Grossmeier            GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg                A18D 1138 8E47 FAC8 1C7D |

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

David Gerard-2
On 16 January 2015 at 17:10, Greg Grossmeier <[hidden email]> wrote:
> <quote name="David Gerard" date="2015-01-16" time="16:27:22 +0000">

>> This is not a great idea because it makes WMF wikis unforkable in
>> practical terms. The data is worthless without being able to run an
>> instance of the software. This will functionally proprietise all WMF
>> wikis, whatever the licence statement.

> "Unforkable" as a binary is not true.


That's why I said "functionally".


> "Not easy to fork without
> implementing all of the pieces carefully" is more accurate. But it's
> still possible, especially since all of the config/puppet code that is
> used to do it is open and Freely licensed.


A licence that was the GPL with the additional requirement of
attaching 1kg of gold to each copy would be technically free as well,
but present difficulties in practice.

What I'm saying is that "technically" is insufficient.


> It ain't easy hosting a site this large with this amount of traffic
> (thanks Ops!) so it's not surprising that "forking" it wouldn't be easy
> either.


However, at present low-traffic copies are pretty easy.


- d.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Ryan Lane-2
In reply to this post by David Gerard-2
On Fri, Jan 16, 2015 at 4:29 AM, David Gerard <[hidden email]> wrote:

> On 16 January 2015 at 07:38, Chad <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: The future of shared hosting

Ryan Lane-2
In reply to this post by David Gerard-2
On Fri, Jan 16, 2015 at 8:27 AM, David Gerard <[hidden email]> wrote:

> On 16 January 2015 at 16:09, Antoine Musso <[hidden email]> wrote:
>
> > So what we might end up with:
> > - Wikimedia using the SOA MediaWiki with split components maintained by
> > staff and the Wikimedia volunteers devs.  Code which is of no use for
> > the cluster is dropped which would surely ease maintainability.  We can
> > then reduce MediaWiki to a very thin middleware and eventually rewrite
> > whatever few code is left.
> > - The old MediaWiki PHP based is forked and given to the community to
> > maintain.  WMF is no more involved in it and the PHP-only project live
> > it's on life.  That project could be made to remove a lot of the rather
> > complicated code that suits mostly Wikimedia, making MediaWiki simpler
> > and easier to adjust for small installations.
> > So, is it time to fork both intent?  I think so.
>
>
>
> This is not a great idea because it makes WMF wikis unforkable in
> practical terms. The data is worthless without being able to run an
> instance of the software. This will functionally proprietise all WMF
> wikis, whatever the licence statement.
>
>
So far all of the new services are open source. If you want to work on
forking Wikimedia projects you can even start a Labs project to work on it.
I don't think this is a concern here.

- Ryan
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123