Is the MediaWiki-Stakeholders-Group still interested in this task? It is prioritized as Normal, but has nobody assigned and no activity since February.

We are still interested in this. Right now we're focused on discussing MediaWiki governance and coming up with a governance model that major stakeholders (WMF included, of course) can agree upon.

Do you mean that in practice this task is stalled and blocked by T89907: Discuss and approve a MediaWiki developer community governance model?

@MarkAHershberger: Could you answer the last question?

In T88265#1410243, @Qgil wrote:

Do you mean that in practice this task is stalled and blocked by T89907: Discuss and approve a MediaWiki developer community governance model?

No, Anyone else can work on this task independently of T89907. I was just saying where my focus is right now.

That said, @Mglaser and @Ckoerner were in a session at the hackathon yesterday that may provide insight on this task.

Just for the sake of keeping my consistent promotion of Phabricator modules, one exist to organize crowdfunding around tasks. See https://secure.phabricator.com/project/profile/1349/ & https://secure.phabricator.com/fund/

I wonder whether we shouldn't simply look at "Investigate ways for funding software features".

The distinction between "third party MediaWiki features" and... Wikimedia MediaWiki features is not that relevant when these features are requested in some non-priority task. Both are waiting for agreement, code, deployment, and maintenance.

The distinction between third part and Wikimedia requesters is not that relevant either. We have many members of the Wikimedia movement that are wishing for the implementation of feature X just as much as a third party MediaWiki users, and we could find in both sides a similar potential to getting organized around a hackathon, crowdfunding, or else.

Qgil writes:

I wonder whether we shouldn't simply look at "Investigate ways for funding software features".

Agreed.

After meeting the IdeaLab people at Wikimania and seeing what sort of funding is available there, I proposed at our most recent Stakeholders meeting that we get some IdeaLab funding first and then, with a success story to point to we could do crowd-funding more easily.

The IdeaLab proposal I had was Making Gerrit access easier for developers new to MediaWiki but I'm thinking of submitting another one that the MW Stakeholders would find more useful: integrating Travis CI testing with gerrit -- especially after a conversation with @mwjames.

In T88265#1007759, @Qgil wrote:

the need to investigate sources to fund the development of MediaWiki features relevant for third parties.

In T88265#1521177, @Qgil wrote:

I wonder whether we shouldn't simply look at "Investigate ways for funding software features".
The distinction between "third party MediaWiki features" and... Wikimedia MediaWiki features is not that relevant when these features are requested in some non-priority task. Both are waiting for agreement, code, deployment, and maintenance.

While I don't care too much who's working on stuff (and whether that's the 1st, 3rd or 5th party), the architecture and its relevance feel important:

• If we talked about functionality in MediaWiki core or in popular extensions, every code addition comes with maintenance costs shared among many stakeholders. For example you have to update some deprecated code in an area that you (being "external" to that area) have never touched but it breaks the build.
• If we talked about functionality pretty much "enclosed" in an extension, that's a rather isolated codebase whose maintenance is pretty much left to the audience interested in using that extension. If the audience loses interest, the extension dies without creating external costs in the community's developer layer. Obviously "audience" can also mean "backing company", see e.g. the WikiBhasha extension now listed as unmaintained.

The rest of my comment is summarizing and quoting Krishnamurthy and Tripathi's “Bounty Programs in Free/Libre/Open Source Software (FLOSS): An Economic Analysis” from 2006. Their paper is about FOSS bounties ran by companies involved in FOSS projects (and there might be more recent papers evaluating bounties) but I see numerous factors which apply and to be aware of, as

In T88265#1007759, @Qgil wrote:

Wikimedia offers grants that potentially could be used for some features

was brought up above.

• Bounty programs can have advantages from the company/corporation perspective:
  • Can reduce development costs.
  • Can lead to a greater number of alternative implementation designs due to rivalry.
  • Can create broader interest in the product.
  • Can change priorities for developer community.
• Bounty programs can have disadvantages from company/corporation perspective:
  • Hard to define the amount of money: If too low it might not attract qualified developers but attract students who wish to learn or developers in countries where salaries are lower (the latter is not bad because it says nothing about their qualification though; the pattern could also be seen in GSoC to some extend).
  • In FOSS a bounty might cover work that someone else might have done for free at some point (if that was considered something to avoid).
  • If code ends up in an unisolated codebase someone needs to spend time to review and judge contributions before merging (though applies also for non-bounty contributions).
  • Regarding potential target groups for bounties specifically: "Typically, bounties have been won by a few people who have worked on projects for a long time." (as the study is from 2006, this might have been superseded by newer studies analyzing more recent phenomena such as websites like "Bountysource" - TODO?)
• Risks for project perspective:
  • Might influence direction that project is heading; short-term orientation may create a non-scalable direction which increases maintenance costs hence long-term orientation is required.
  • Potentially attracting developers which do not know the direction and context of project.
  • Potential rivalry with volunteer developers and potential withdrawing of them.
  • Potentially bypassing maintainers if bounty organizers decide which tasks are pushed/prioritized instead of the actual maintainers/community.

Source: Sandeep Krishnamurthy, Arvind K. Tripathi: “Bounty Programs in Free/Libre/Open Source Software (FLOSS): An Economic Analysis”, in: The Economics of Open Source Software Development, pp.165-183. Editors: Jürgen Bitzer and Philipp Schröder, Elsevier Publications, 2006

Some ideas:

• Nuvola Player's funding page.
• Synergy is open source but charges for compiled versions.

A mix of T56425: Provide an opt-in ability to register the user's MediaWiki installation, T88265: Investigate sources to fund third party MediaWiki features and T951: Compile a List of MediaWiki Third Party Customers: If I remember correctly Kvantomme (Twitter handle) at this year's FOSDEM:
There is a "Drupal 8 site upgrade report" service that can automatically scan your installation: A service that that collects information from drupal.org, the site scanner itselfd, and an API that schedules the scan. So this does "phone home" but it also identifies customers who can potentially financially sponsor the development of a certain module (MW: "extension"). Hence the relation to 3rd party financing.

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

Note that @GroundGinger and @Ckoerner said they would start working on a Patreon effort.

A specific way to make this topic move forward is to throw funding or dev time (Ruby on Rails app) to Bountysource to finish[1] supporting Phabricator.

https://github.com/bountysource/core/issues/435
https://www.bountysource.com/issues/1384856-add-support-for-phabricator

[1] it already can extract the name of a Phabricator ticket so there is definitely some code already there.

crossposted in T88265

See also T231814

See also T239189

Should this Task also be added to the Wikimedia-Fundraising Workboard/Project ?

Somewhat related: Investigate payment button for MWStake