MediaWiki

Release Management RFP/2013/NicheWork and Hallo Welt!

< Release Management RFP | 2013

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

edit

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

edit

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

edit
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

edit
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

edit
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 calculation is 48 weeks.

About the people

edit

Mark Hershberger (hexmode) / Nichework LLC

edit
 

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.net, 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:

Markus Glaser (mglaser) / Hallo Welt! GmbH

edit
 

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:

Endorsements

edit
  • As long time MediaWiki developer and facilitator of the MediaWiki localisation process, I would like to endorse this proposal. Both Mark as well as Markus are community members that have demonstrated their commitment and skills, each in their own area, and each often aimed at third party use of MediaWiki. I have confidence that together they are able to take responsibility for the MediaWiki release process and improve it per their description above. siebrand (talk) 17:31, 13 June 2013 (UTC)[reply]
  • Both these people have been involved with MediaWiki for quite some time, and also have experience not just with the WMF, but also third parties. Mark has already been doing much release management work on his own free time, which demonstrates he is quite committed to the issue. I think release management would be in good hands if it was managed by Mark and Markus. Bawolff (talk) 17:59, 13 June 2013 (UTC)[reply]
  • I definitely agree that mediawiki has critical issues, one of them is very poor backward compatibility with 3rd extensions as well as poor optimization for non-wmf use (complicated deployment, overloaded with stuff that is useful for wmf purposes only). Mark has been working on mediawiki project for a very long and has a lot experiences in many areas. The proposed improvements, such as LTS releases, sound very promising! Petrb (talk) 07:17, 14 June 2013 (UTC)[reply]
  • I believe that the proposals here will go a long way towards making MediaWiki a stronger platform that is much easier to use by end users. In particular the web based configuration is desperately needed. Also creating a uniform package (I.E. no node) will help go a long way towards massive community adoption and involvement. blobaugh 5:54, 18 June 2013 (UTC)
  • two skilled and experienced persons. Structures in place (two successful businesses). BlueSpice is also very promising. --Manuel Schneider(bla) (+/-) 21:07, 19 June 2013 (UTC)[reply]
  • These two can really make the work done. I'm following HalloWelt! for some time and I can say that their development process is really impressive. Also I like that the most pressing problems are listed here and scheduled first. MediaWiki will become a lot more attractive as a software after these improvements. -- Yury Katkov
  • The spirit and direction of the ideas presented in this proposal align well with keeping MediaWiki viable and thriving. I agree with the priorities outlined, and particularly agree with establishing more visibility into the entire MediaWiki ecosystem regarding extension compatibility, spam and usage (the same goals for why I made WikiApiary). — 🐝 thingles (talk) 14:05, 24 June 2013 (UTC)[reply]
  • I've worked with both Mark and Marcus in the past. I've worked with Mark at the foundation, and Markus through both consulting jobs and through the foundation. Mark currently and in the past has handled our release process and I have faith that he can handle this process in the future. Markus is well versed in MediaWiki development and support and understands the shortcomings of our current process. I think they are natural candidates for this process and I believe they'd handle it well. --Ryan lane (talk) 21:33, 26 June 2013 (UTC)[reply]

Feedback

edit

(Moved to the talk page.)

Thanks for the detailed & thoughtful proposal. I have a couple of questions:

  • 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?

Thanks! -Ori.livneh (talk) 07:43, 13 June 2013 (UTC)[reply]

I've given my answer on the talk page. If you post your question there, we can re-arrange this so it looks right. -- ☠MarkAHershberger☢(talk)☣ 14:26, 13 June 2013 (UTC)[reply]
Moved your first question to the talk page and answered there. --Mglaser (talk) 10:44, 16 June 2013 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Release_Management_RFP/2013/NicheWork_and_Hallo_Welt!&oldid=3757667"