Hello fellow consultants,
I am hoping to start a project to create some MediaWiki products. What is a product? In this context, it is core MediaWiki, plus a set of extensions, plus a set of pre-defined wiki pages that together create a data structure, all working together to support one usage type. I think this could potentially make a big change for MediaWiki consultants, in that it would let us market our services to a much bigger audience. The number of people and companies looking to use MediaWiki - or any wiki at all - is substantial, but still a tiny percentage of people who have some business need that could potentially be met by MediaWiki. (Which really is almost everyone, no?)
Let me give an example. Let's say someone is looking for a project management solution. We know that MediaWiki can be used as a project management tool. But if someone simply searches for a project management application (even an open source one specifically), they will never find MediaWiki - it won't show up in a web search, or on any list of project management applications. And who would think of using a wiki for project management?.
Now, let's say that a "product" exists, called, say, "Acme PM". It consists of MediaWiki, plus some necessary extensions (ParserFunctions, Page Forms, Visual Editor, etc.), and then a bunch of data structure pages (for people, tasks, projects, etc.). In practice, it's not that different from the kinds of things many of us have implemented before. But as a concept, it's totally different - because now we have something tangible to point to, with its own name, marketing language, feature list, screenshots, etc. (And in the future, hopefully its own testimonials too.)
There is any number of potential products that could be created: besides project management, there could be products for business process management (BPM), customer relationship management (CRM), quality management (QM) - which in practice I believe is often tied to ISO 9001 compliance, but it could be other things too - document management, technical documentation, etc. (And every one of these products could actually be multiple products, since there could be different versions for different languages, or Cargo vs. SMW, etc.)
How would this be achieved technically? For the actual software, I'd imagine that there would be something like Docker images to make it easy to install MediaWiki and the relevant extensions. Then, for the wiki pages, I think the best current solution is to use the Page Exchange extension, which I released about six months ago:
It lets a wiki administrator easily install - and update - "packages" of wiki pages. (You may remember I sent an email about this extension to this mailing list earlier this year, back before it was released and I was thinking of calling it "Package Installation Manager".)
All of this would be open source, with instructions available on how to install each product - though of course, anyone could also set up their own hosting for one or more of these products.
There's nothing stopping anyone from doing this already - with or without Docker or Page Exchange - and there are already consulting companies that put out their own branded products for one or more of these use cases. But I think it makes sense to combine forces to create a general product suite, for a few different reasons: it's less work to create, it reduces customer confusion about what to choose, it reduces customers' fear of "lock-in" (especially if some of these products involve non-open-source elements), and it allows for more input from domain experts. On that last point: there are surely people out there in the MediaWiki community (and probably on this list) who are experts about BPM, QM, etc. - but I doubt there's anyone who is an expert on all of these things, and would know what a good MediaWiki-based solution should look like for all of them.
There's one more advantage I can think of to having this kind of generic suite, and that's that it would allow for rebranding MediaWiki. Let's say the products (or product categories) are referred to as "Acme PM, "Acme BPM", "Acme CRM", etc. If these catch on, people could start to refer to themselves as "Acme consultants", there could be jobs advertised for "Acme developers", etc. (No, don't worry, I don't think "Acme" is actually a good name to use.) I've been trying to popularize the use of the phrase "Enterprise MediaWiki" for what we do, but it hasn't really caught on. A true separate name - one that doesn't necessarily even include the word "wiki" - could be catchier, and make it clearer to people that this is more than just having their own internal version of Wikipedia.
This is a lot to digest. But I would really like to hear what people think. And if people generally like the idea, it would be great to know if anyone is willing to help in this effort. I should note I already presented this idea a few days ago at the monthly MediaWiki Stakeholders' Group meeting, which a few people on this mailing list also attended. It got some positive reaction there, which was definitely good to hear, but most of the people there were not consultants, and I'd imagine consultants will ultimately be the ones who do most of the work to create it, and will determine whether this idea gets off the ground or not.
-Yaron
--