Communicating maintenance capacity and prioritization

[ariya]

So far we have not been doing a great job at communicating the current state of maintenance. This is a discussion to find a better way of achieving that.

The team behind PhantomJS (@ariya @vitallium @zackw and other occasional contributors) is committed, yet we remain a small team. None of us is paid to work on PhantomJS, thus we carry out the contribution during our spare time. For the sake of discussion, let's say that our estimated total effort is 4 hours/week.

Meanwhile, the users of PhantomJS continue to grow and the demand keeps increasing. Every user wants the latest updated WebKit, full ES6 support, and zero crash. In theory, to moderately keep up with this demand, it requires at least one full-time sofware engineer, an equivalent of 40 hours/week of work.

The impact of our limited maintenance capacity is that the progress pales in comparison to the skyrocketing user demand.

Issues are piling up in the issue tracker because the triaging rate is much lower than the reporting rate. Triaging is not difficult (see #13861) but it takes a lot of time and yet there is very little external help.

When an issue is not being looked at, users affected by the issue become disappointed (see the most recent example #12750). Given the limited maintenance capacity, prioritization is inevitable. Sadly, that perspective is not taken into account by the users and the message comes across the wrong way.

We are still happily making progress, and we do not plan to stop anytime soon. In some cases, our progress is judged by the commit statistics which (in the case of this project) unfortunately do not correlate with the effort (we often worked on a big 100-hour task that resulted in just one git commit). And when an user is not feeling the progress because our current focus does not overlap with their needs, it triggers a sweeping generalization that there is no progress at all.

What is the best way to ensure that every user is aware of this mismatched capacity vs demand?

Suggestions are welcomed!

[annulen]

Some thoughts:

• It may be a good idea to start crowdfunding campaign with goal of fixing most prominent bugs, and hire developer for this money. Users who pledged more money can select more issues for priority fix
• Promote self-service as the best way to get issues fixed timely. Maybe more developer documentation is required to lower barrier of entry
• https://www.bountysource.com - if someone cannot self-service, there may be someone else to earn a little money on it

[thoop]

Issues are piling up in the issue tracker because the triaging rate is much lower than the reporting rate

How can we, as a community, help on the issues side of things? I'd love to help in the very small amount of free time I have, but I feel as if the barrier to entry is high just for curating issues.

I know you mention #13861 but your suggestions there don't seem like they would be helpful besides on a few popular issues.

PhantomJS has a high surface area since it can be used with nodejs, webdriver, ghostdriver, selenium, etc. And that's not even mentioning all of the different browser features supported by PhantomJS/Qt, operating systems used, etc. That makes it hard to know what to prioritize, what is actually an issue with PhantomJS and not an upstream or downstream dependency, or even validate a reproducible test case.

That being said, I think it would be great if we could do those things for the contributors and free up your time for other things. How can we enable that, or reduce the barrier to entry on curating issues in general?

[gsouf]

@ariya I would like to mention #13797 in which there is 0 output from the team. This issue is very ennoying because it's written in the doc but it does not seem to work and it looks like the team is not even aware about it. That's a factor of frustration. A good thing would at least to notice the users that you are aware of it, and give some clue about an eventual fix (or no fix) like "okay, we will fix this soon" or "hard to fix for the moment, we need design decision"

[ariya]

@annulen All good suggestions, thank you! It doesn't seem likely that I personally have time to do any of these 3 steps, but the very least, I do plan to improve the state of the documentation (both for end-users and future contributors).

[ariya]

@thoop Should we have a flowchart on issue triaging? I can write down something on the wiki and we can iterate from there.

[ariya]

@gsouf You're describing the precise problem that we're facing (in your own words). The team does not have a chance to be aware of every single issue because we tackle 2 issues/day while we have 10 new issues/day being reported.
If you are in that situation, what would you do differently instead?

[gsouf]

@ariya I dont know what I would do, that's why you started a few issues related to this in order to find solutions!

[thoop]

I think improving documentation is always a good thing, but I don't know how much a flowchart would help besides superficial issues.

I think zackw was doing lots of issue triaging for a while, right? I don't know what all they were doing, but did it help with your availability to do other things? I remember seeing lots more labels on issues than I see now.

Maybe I can jump in and just try to start commenting on issues and report back with any ideas on how it would be easier to get others to do the same in the future?

[gsouf]

I think that if you dont have enough time to look at all issues, a first step should be to find some people to help to label issues, answer question issues and close undesired issues. That would already help for a lot of issues

[ariya]

@gsouf If you have a concrete idea on how to find those people, please chime in at #14543.

[Ivanca]

The guys at Node.JS are making money from working on it, the same thing with the guys at MariaDB and many other big Open Source projects. That's the best way to assure the future and health of an open source project. So, making money from PhantomJS should be the number 1 issue on the issues tracker (perhaps a private issue only few can see)

It doesn't even have to be a startup of something of the sort, just doing consulting for big companies can bring a lot of cash. Creating a web interface for phantomJS would attract millions of dollars in investment, specially if Ariya is behind it (or at least has his blessing)

[ariya]

@Ivanca Setting up a business or a consulting service takes a lot of time. It's definitely something that I personally can't afford doing.

This is free software, if there is a big business benefitting from PhantomJS in any kind of form and that benefit goes back into improving PhantomJS (i.e. paying someone to fix something), I don't think anyone will have any problem with that. See also #13861.

[jnicholls]

@ariya Sounds like you need help sir. I like the crowdfunding suggestion.

[Ivanca]

So the project is bigger (and more popular) than you can maintain; all right, that happens. But keeping expectations low is not going to do any good; so I think the project has 2 success paths:

1. Someone close to build a business around it, it doesn't have to be you, but with founders you trust enough to give them commit access; there is hundreds of ways to find them, one is organizing a small (non-proffit) hackathon and evaluate projects (and teams) that come out from there.

2. Look for different people to maintain it entirely, someone willing to dedicate it enough time to make it its full time job.

[gsouf]

@Ivanca I'm pretty sure that some big companies are ready to back the project as a sponsor, and they will love to have their logo shown on phantomjs homepage.

Everyone has profits: for them it's good for the reputation, for you you can pay maintainers.

[ariya]

Seems that the discussion expands to cover:

• How to communicate the mismatched of capacity vs demand
• How to increase the maintenance capacity

Let's keep this issue focused on the former.

For the latter, I create another meta issue #14548 Increasing maintenance capacity so please bring up your ideas there!

[mattab]

Thank you for the great work on Phantomjs2 - and all the best for the future! We support your awesome contributions to open source & the community

[ariya]

@mattab Thanks for the kind words!

[puzrin]

2c:

• see pledgie campain of ttfautohint. It cost nothing to try do the same. Just show a clear goal to reach and what you can suggest for next milestone.
• bountysource in each issue to bump priority (already mentioned above).
• more regular releases, IMHO at least every 2 months. Firefox / Debian had similar infinite release problems in the past. Don't repeat that mistake, pleeeeeaze.
• try to fix simple issues first. In general (not everywhere, but very often), 10 pending simple issues are much more irritating than 1 pending difficult issue.

[dogancelik]

Like @annulen and @puzrin said, enabling Bountysource for this project is a good way to prioritize issues. This way, people can support the project financially while giving focus to important issues. Also Bountysource Salt for monthly donations.

[ariya]

For the new policy on auto-closing of (stale) issues, see #15395.

[AndrewSav]

@ariya so how does the bot knows that the three conditions are not fulfilled? To me it looks like some (many?) of these issue have them there. Rather then wholesale closing to make the team feel good, may be specify what's wrong with the issue in no unambiguous term (not just "oh some info is missing" but, what concrete question about the bug report and following discussion you have, and what you feel is lacking) and let the community address that. Give ample time to address it - 3 days is not realistic, some of the issues above was unadressed by the team for years, and yet, you close them only 3 days after marking them stale. 90 days would be more reasonable. And only then, if the information is not forthcoming, close it.

[onlyjob]

Nothing disappoints me more than a legitimate issue closed without an action (e.g. by "stale bot").
That discourages contributors from reporting problems (and solutions) and from cooperating by sharing information in opened tickets. Issue management based on denial and institutionalised forgetfulness can never succeed. Leave the issue opened and you'll never know who might show up one day with a patch.

[kensoh]

My view will most likely not be welcomed, but I'll have to share it nonetheless.

I'm a PhantomJS user, through CasperJS. Am still actively using PJS because I built a couple of popular digital process automation (RPA) tools based on PJS as the execution engine.

The context for PJS is it has become so huge that the ratio of users versus maintainers and active contributors from the community has become dismal and severely unbalanced. Look at the thousands of issues raised. It is easy to say to keep unsolved issues open in the hope that one day someone will come from the community to offer a PR. But that is not going to happen, from my experience being a maintainer of 2 active popular open-source projects.

The open-source world has changed a lot in the last decade. Today, a popular open-source tool would be used by an overwhelmingly large number of users. Though that is good in terms of user impact, it makes any popular open-source tool with significant degree of technical complexity practically impossible to be maintained as a hobby anymore. The efforts required would be similar to a full-time job, or more.

It simply does not make sense for a maintainer to give up a full-time high paying job to continue maintaining it full-time. Doing that is great for the community, but is being irresponsible to the maintainer's own family well-being and financial security.

And don't expect users to come and contribute PRs and solutions. This happen rarely these days. Why? As businesses become more open and actively use open-source tools, many users simply shop for tools to use, demand solutions and support and fixes for free, so that they can get their job done. But their company is not going to say, hey that's a great tool you are using, why not spend 5-10% of your bandwidth contributing a PR to it to improve? That isn't possible because the business is driven by profits, why would anyone want to spend resources in something which doesn't bring back revenue? Why not wait for some other users to do that? The end result is, only the maintainer try to keep project afloat until a point where it is no longer possible.

Since there are no active contributors from community, the burden rests on the maintainer to do what's best for the project. Instead of letting a project dies off quietly into oblivion, which is the default path, making the project active and closing all issues which are not going to be worked on helps the maintainer to have visibility of what's to be done to advance the project. Vs trying to solve 1-2k open issues which the community has not come to assist with but demands free solutions. To me, an actively maintained project with specific focus by the maintainer is in every way better than an archived project which no longer gets new commits.

So I 💯% support what is being done here, and believe that it's necessary for the project to move forward. The maintainer of any open-source project has the big overview of everything, versus a user which is only specifically focused on that issue which causes pain-point for him or her. So the maintainer is uniquely positioned to be able to make the best decision and take the best path forward on behalf of the overall user community. This of course, sometimes will offend some users. But hey, this is a free open-source tool which the maintainers have been pouring a lot of countless hours into maintaining it. At the sacrifice of using the time to exchange for good $ instead. I know that because I do that too for my own open-source projects. But it is simply not sustainable in a world with rising costs, increased uncertainty, and increasing number of open-source users from the business world simply trying to take a free ride without ever thinking about contributing back.

In my view, the business world has completely subsumed the open-source world. And except for some exception projects, this new open-source world is no longer the idealistic help-build-software-together world it once was. CC @ariya @vitallium @n1k0

[gsouf]

@kensoh the real problem is maintainers failed at making this project profitable and being able to work full time on it.

[ariya]

Hi @AndrewSav @onlyjob, I understand your perspective. Believe me, it's not easy at all for me to decide to continue on this path (it's a compromise after all, not my personal desire).
If you have a better idea and you are willing to actively purse the implementation, I'll invite you to work on it! Send PRs, volunteer to triage, anything. You're always welcomed!

[ariya]

@kensoh the real problem is maintainers failed at making this project profitable and being able to work full time on it.

True @gsouf! But I can live with that failure, as long as there's still folks benefitting from this project.