Release Management RFP/2013/NicheWork and Hallo Welt!

Mark Hershberger (with NicheWork LLC) and Markus Glaser (with Hallo Welt! — Medienwerkstatt GmbH) will form a partnership. Mark and Markus have already worked successfully together in the MediaWiki testing group. They are convinced the proposed joint venture will benefit the release process: their experiences complement each other, and with their different areas of focus in MediaWiki development, they can provide a stable basis for MediaWiki's release management.

With the two companies working together, a physical presence is established both in North America (Nichework) and Central Europe (Hallo Welt!). In addition they're very comfortable with the tools of online collaboration such as irc, video conferencing, wikis, bugtrackers, forums, blogs, real-time document sharing and plain old phone calls.

Problems with MediaWiki release managment
We see several problems with release management. Many of these are simply the result of Wikimedia focusing on its very popular, donation-generating sites (Wikipedia, Commons, etc.) and leaving third party's use of MediaWiki (who use the software without fee under the GPL license) with only ad hoc support.

This means that new efforts — such as the Visual Editor, which relies on the installation of a node.js server — are undertaken without considering the needs of MediaWiki's installed base.

Further, while releases of MediaWiki mainly target 3rd party users, their needs are scarcely reflected in the software. There are a lot of areas where this can be addressed. This was discussed at the NOLA Hackathon, during a session initiated by Markus Glaser.


 * Skinning sucks
 * One of the first things most people want to do when they install a piece of software is customize the appearance. Since MediaWiki's solution to skinning isn't clear and has changed significantly in recent years, many people are afraid of upgrading.


 * MediaWiki suffers from a lack of web-based configuration control
 * The Foundation employs a small full time operations staff and relies on them to make changes in the configuration of its sites. As a result, the deployment and configuration of MediaWiki itself suffers.


 * New public MediaWiki installations are quickly overrun with spam
 * Because Wikipedia has a very active community, many of the tools to fight vandalism are not built into MediaWiki and are meant to be run by individual editors. This means that a new MediaWiki user's site will quickly be overrun with spam since the user doesn't realize the amount of manual labor Wikipedia requires.


 * No built-in help system for Wikitext, lack of base templates, missing gadgets
 * Much of the functionality of Wikipedia exists in on-wiki content. This means that MediaWiki simply doesn't operate the way a naive user expects when it is first installed.  With the introduction of Scribunto and the growth of gadgets, this situation is likely only to get worse if it is not addressed.

Initial improvements
These are our goals for the first year. During the first year we'd like to remain relatively conservative in order to establish ourselves. We will make some initial attempts at crowd funding and attempt to fund some small but significant improvments for third-party users.


 * Maintain two major releases per year
 * This will include security releases as needed and point releases to fix significant bugs in the major releases.


 * Continuous integration
 * We'll work with the WMF's QA team to improve automated testing for MediaWiki itself and maintain interface stability.


 * Work with extension developers
 * We'll begin working with extension developers to set up reliable API/deprecation standards and communication so that the MediaWiki ecosystem can begin to thrive.


 * Start developing lasting relationships with Open Source organisations to improve sustainability
 * This work will continue work done with the LTS version of MediaWiki and Linux distributors, but move beyond that to work with organisations whose focus is the sustainabiliity of Open Source software.


 * Kickstarter fundraising to support implementation of new skinning system
 * Our first attempt at fundraising will be done with Kickstarter to fund the development of a better skin system for MediaWiki. We'll set up a skin exchange and publicize it as well.


 * Begin fostering relationships with large third party wikis
 * During the first year, we'll also be working to develop relationships with third party wikis try to find ways to involve their developers in the MediaWiki ecosystem.


 * Work with vendors such as Microsoft to get funding to improve support for their products
 * Support for MSSQL, Azure, and Oracle SQL will improve if there is funding to help develop these features.

Longer term improvements

 * Improve the tarball
 * We'll look for ways to improve the shipped version of MediaWiki by improving on-wiki documentation, available functionality, anti-spam controls, web-based configuration and upgrade-ability.


 * Improve the test environment
 * We plan to add to the test environment. Hallo Welt! does have its own testing environment with Oracle and Postgres running. That should be moved to labs and be maintained there (Oracle and Windows environments: depending on licence, otherwise we can keep it within Hallo Welt! or move to Azure). Installation can also be tested automatically.


 * Improve the extension management
 * In the long term, we need to get a QA process going for extensions. It is not clear which MediaWiki version they work with. Security and performance issues are not systematically addressed. Updates and maintenance are not ensured.
 * As a first step, introduce a Wordpress style rating system, where users can indicate which version of an extension worked for them with which MediaWiki version.
 * We will work with extension managers to create a release process that extension developers can opt-in to.

Organisational development and vision

 * Set up an interest group
 * We aim at having a sustainable organisational structure for continuous MediaWiki release management and consideration of the interests of all implementers. A first step will be setting up a MediaWiki user group for release management and 3rd party use. This group will be open for organisations, interested volunteers and core contributors as well as companies and MediaWiki users.


 * Support an ecosystem
 * Like any other open source project, MediaWiki should have and foster a vibrant ecosystem around the core software. This involves an active commmunity of extension developers as well as added value services provided by third parties. A broad basis of users leads to stability and innovation. This ecosystem needs to be actively supported. We expect a lot of give-backs to the benefit of MediaWiki development.


 * Find additional sources of funding
 * Funding of MediaWiki development beyond the direct needs of Wikimedia projects needs to become more independent from WMF financial resources. In order to do so, we will aim at activating some additional source, such as contract work, directed donations, crowdfunding, sponsors. Our first attempt with be using Kickstarter (mentioned above).


 * Pursue long-term relationships with organisations that provide infrastructure for Free, Libre, and Open Source Software (FLOSS) projects
 * The Bus factor is a real concern. To mitigate this risk, we'll look for a home for this work that will outlive our organisation.

Budget

 * Rate
 * Our regular billing rate is ~$125/hr. We are willing to charge WMF a reduced rate of $65/hr.


 * Estimated time
 * We estimate 24 hours of work a week. These include all technical aspects of producing the release, supporting MediaWiki users, working with the communities and raising funds for the work. Time will roughly be distributed equally among those tasks.


 * Total cost
 * The total cost will be ~$75,000/year. This takes into account there will be some holidays. The basis of this calcuation is 48 weeks.

Mark Hershberger (hexmode) / Nichework LLC
Nichework and Mark have been helping businesses and organisations make use of open source software for the past 17 years. These include adapting Joomla and KnowledgeTree to the needs of the Ministry of Health in Uganda, introducing IntraHealth's iHRIS Software Suite to TranslateWiki, helping Sherwin Williams upgrade their internal MediaWiki installation and adapt it to their needs, and working with highly customized MediaWiki installations such as WikiPathways.

Mark also has extensive operations experience and, as a result, is familiar with the end user's experience of running Open Source systems as part of the production environment.

Mark has managed the MediaWiki releases for the past year and has been actively supporting users on the Support Desk. During that time he has worked with Fedora and Debian to update their MediaWiki packages and establish MediaWiki 1.19 as a Long Term Support (LTS) release. He has already provided a release schedule so that third party users will know what sort of support they can expect.

During his work as the Bugmeister for Wikimedia, Mark met with users based in India, helped address the issue of devnagari digits on Wikipedia and met with users who had an interest in RTL languages (i.e Hebrew, Arabic, and Farsi) in Berlin to make Wikipedia more usable in those languages.


 * Mark has worked with the MediaWiki community to begin bundling extensions in the main tarball.

Selected projects:
 * mediawiki.el. A tool to edit MediaWiki sites in Emacs using the MediaWiki API.
 * MediaWiki's RSS extension. Addressed some security concerns so it could be used on the WMF wiki
 * Familiarity with Wikimedia's tarball release scripts.
 * Contributed a variety of PHP packages to Debian and Ubuntu, including the first php-xdebug package for Ubuntu Hardy.

Markus Glaser (mglaser) / Hallo Welt! GmbH
Hallo Welt! specialize in professional MediaWiki implementations, mainly in an enterprise context. Hallo Welt! has more than 100 customers of all sizes, ranging from 10 to 120,000 employees. Clients include large companies like IBM, Hilti or Danone, as well as non-profits like Desertec, Co:llaboratory and also Wikimedia Germany. Our projects focus on knowledge management, expert communities, project documentation and public knowledge bases.

Because Hallo Welt! use MediaWiki to meet its client's needs, they have significant developer resources in LAMP-stack and web technologies that they've used to create MediaWiki extensions. They also have operations resources to run webservers, manage caching, maintain Java applications, etc. as well as provide interoperability via protocols like LDAP, SOAP, REST, and external APIs.

Building on this experience, Hallo Welt! releases af MediaWiki distribution called BlueSpice, which includes a set of over 40 extensions to help with usability, security, administration, process management and communication. Hallo Welt! has 15 employees (eight of them developers) and, as a result, is able to guarantee stability and reliability for projects they undertake.

Markus Glaser is an active MediaWiki developer. As a member of Wikimedia Germany and the chair of the Chapters Association, he is familiar with the wider Wikimedia world quite well.

Markus and his team speak German and English. Some of them also speak French, Spanish or Slovak.

Selected projects:
 * BlueSpice . A set of extensions aimed at making MediaWiki suitable for enterprise contexts. (15 releases since October 2011: 6 stable, 5 beta, 2 RC, 2 patch)
 * PagedTiffHandler. An extension for displaying multipage TIFF images. Used on Wikimedia wikis.
 * WindowsAzureStorage. An extension to make MediaWiki use Windows Azure as a file backend.
 * Selenium Framework. A test framework for MediaWiki using Selenium.
 * Elgg: Q&A-Plugin
 * JWiki. A Joomla! component integrating MediaWiki.
 * In cooperation with Microsoft, Hallo Welt! has built a MediaWiki package for Windows Platform Installer / Web App Gallery

Feedback
Thanks for the detailed & thoughtful proposal. I have a couple of questions: Thanks! -Ori.livneh (talk) 07:43, 13 June 2013 (UTC)
 * I noticed that PagedTiffHandler isn't explicitly versioned. Why?
 * How could we make VisualEditor more usable for third parties? As release managers, what role would you play in this process?