ngrok

[caalberts]

• Where is the project currently hosted? https://github.com/inconshreveable/ngrok

• Is the project written only in Go, or does it contain other languages (beyond scripts)? Core in Go, some Javascript for web UI

• Has the project had any recent activity? Last commit was 3 years ago. The maintainer has shifted focus to a closed source v2.x.

• Does the project have a maintainer, or a maintainer looking for someone to take over the project? From the status section of README:

• it's no longer supported or maintained, unless to ensure it compiles

• No new features will be added. Any pull requests with new features will be closed. Please fork the project instead.

• Are there active projects which replicate the popular functionality of this project? There's Serveo but the code isn't available

• Do you have any example projects that make use of this package? Looking at how frequently issues are filed, it seems to be highly used.

• Are there any outstanding critical bugs that result in the library being totally unusable or insecure?

• Is there anything else you'd like to mention about the project? It's worth investigating if this project can be adopted and how it can coexist with ngrok v2.x. The open source version would be useful for self-hosted use cases, for example in restricted networks that don't have access to https://ngrok.com/

[theckman]

It's interesting that you mentioned this, because I wondered if it made sense for us to build something like this from the ground-up. Like an open source implementation of the v2.0 featureset, without relying on any of the older code.

If we adopted this, what do you think we would do? Add a lot more features, or just keep it alive?

[antham]

@theckman at a point if you host a project and maintain it actively, I guess you would need to add features because people would come with good ideas or even with good implementations and it would be hard to say no, it won't make sense.

[niaow]

@theckman I was thinking the same thing! We could implement via a package that did the basic functionality (e.g. ListenAndServeGofrs-ish thing) and command-line client/server applications using this package.

[trevorstarick]

I use Ngrok all the time and would love to help build and maintain a open source derivative!

[caalberts]

The appeal of ngrok to me is that it doesn't add noise to a codebase. It's a versatile tool that boosts dev productivity. Being a CLI, it's compatible with servers written in any language.

In that regard, I would like to see it remain as a CLI tool. How to get there, be it maintaining a fork of v1.0, rebuilding from ground up, is up for discussion.

@trevorstarick feel free to jump in since you use it all the time.

One thing I would like to get clarified, is gofrs objective to maintain Go packages only or any open source projects written in Go?

[trevorstarick]

The goal of the project is to maintain packages and projects, as well as create useful tools to support that goal.

For example, issue number #8 looking into maintaining godef

[theckman]

I think we'll pass on ngrok for now.

I know @trevorstarick is thinking about an open source rewrite that tries to implement all of the ngrok 1.0 features, and to see if there are any features we want to emulate in v2.0. We can raise an issue for that once we come up with a proposal.

Because of v2.0 getting some paid functionality, I think we should avoid making use of ngrok v1 code. With that considered I'm going to close this issue.