I'd like to open this tracking issue to open a discussion about the future of GopherJS, and the health of the project. The goal here is to try to answer the question: what does the future and roadmap look like for GopherJS? This is something that affects both the users and contributors to the project.

Project Health

Right now, the latest GopherJS 1.11-2 supports Go 1.11.x and works on macOS and Linux. On Windows or other OSes, it requires setting GOOS to one of two supported values, as documented at https://github.com/gopherjs/gopherjs#installation-and-usage, and system calls can’t work (which means gopherjs test can’t be used on those platforms). It can be described as functional, but with known limitations.

There are many open issues and PRs that haven’t been fully reviewed and merged. In the last few months, there hasn’t been much activity in that regard. This is indicative of declining health of an open source project.

At this time, there are 4 people with push rights to the main GopherJS repository: @neelance, myself, @hajimehoshi, and @myitcv as of recently (issue #799). To land a PR into master, it needs to go through code review and get a LGTM from at least one other maintainer. Richard has been quite busy working on Go WebAssembly and elsewhere. I have a full time job now, leaving me with less time to spend on GopherJS than before. Hajime and Paul have other commitments too. Being an open source project, we’re all volunteers working in spare time, so the resources we can dedicate to the project are limited.

From my side, I can say that I’m committed to doing my best to keep GopherJS running in its current state: on macOS and Linux, and compatible with the current Go releases (1.11 right now, 1.12 in a few months, 1.13, 1.14, etc.) for the foreseeable future. I can’t spend much more time on fixing the remaining issues and reviewing incoming PRs, at least nowhere near what I’d like.

I think it would be very helpful for contributors to have a better idea of what kind of PRs they can/should send and if it has a chance of being reviewed.

Ways To Proceed

We have a few possible strategies to choose from about what to do next. I will enumerate them below, and make a proposal for a suggested plan of action below. However, if there exists a better option that we haven't thought of, your input will be greatly appreciated.

Option A: Do Nothing

I want to make it clear that this is not a good option. However, this is the default outcome that happens unless we actively work towards one of the other options.

This option is to do nothing and let things keep going as they are. This isn’t great, there are many stale PRs and it’s unclear to contributors if they should spend time creating new PRs, and whether their PR will be properly reviewed and eventually merged or closed.

The outcome of this path is that the health of the open source project will continue to decline and it will be perceived closer to being a dead project.

Option B: Limit Scope, Cull Contributions

This option is to more actively limit the scope of contributions we accept, and communicate this (e.g., in README, a CONTRIBUTING file, etc.). Start closing PRs that are out of scope, since we don’t have the time required to get them reviewed.

This option takes active work and time spent, as PRs need to be triaged and closed, sometimes even when there are valuable changes in them. However, the benefits are that the project health is improved and it becomes easier to make progress. Contributors are saved from spending time on out of scope PRs unnecessarily or kept wondering when their PR will be reviewed.

Option C: Somehow Increase PR Reviewing Resources

This option involves trying to get more help with reviewing existing PRs and getting them merged in. I don’t know how to make this happen. I don’t think we should be sacrificing quality and merging changes that aren’t thoroughly reviewed and tested. Many of the fixes require significant time and effort to investigate and understand how to resolve in the best way.

This option would be great if it were viable, but we need to be realistic and understand it can't happen on its own.

Suggested Plan

From initial discussions with other maintainers, we are currently leaning towards Option B, limiting scope to be more manageable given the resources we have available, cutting down on feature development, but maintaining functionality and support for new Go releases as they come out. We should also do a better job of communicating it so that both contributors and users have a better idea of what to expect.

However, I’d like to invite input from the wider GopherJS community and hear feedback, suggestions for how we should proceed, and what’s best for the future of GopherJS.

From myself and other maintainers, I'd like to thank everyone who has contributed or used GopherJS over the years. I think it's a phenomenal project that has enabled people to build some really interesting things, and allowed us to use Go in more unexpected places! It should continue to work well for many years to come, until there's really no need to keep supporting it.