Seems that, unlike Sidekiq, this starts as a heavily commercial solution, and it shows. Landing page has a pretty big "Buy Pro" call-to-action button. Features like support for notifying slack/etc I'd expect to be present in a free version. Open source feels more of an afterthought. I don't feel comfortable using even the free version, simply because if the project fails financially, it is likely to be dropped altogether.
The fact that there is a commercial version is proof that mperham wants and expects the project to continue sustainably.
That said, the open source version provides more than Monit in a better, easier to deploy package. I think that right there is incentive enough to use it. Plus, if you want to fork it and add your own specific notification channels, here's the source:
I agree that ease of use is the strongest reason to use this.
Just because mperham wants the project to be sustainable doesn't guarantee it. However, if sidekiq Pro would have failed, Sidekiq would easily survive simply because of huge open source community. With inspeqtor it's not so clear.
"Route alerts to your team chat room" is listed as a Pro feature. Any PR implementing it is unlikely to be merge in. And creating a separate fork for a relatively small feature should not really be an answer to an open-source project.
Long story short: I'm new to Go and wasn't sure how to manage the codebases for both an OSS product and commercial product together so I built the two in tandem to work out the kinks. Since the commercial product was already written, why not sell it from day one?
The OSS product is targeted to small teams, individuals and hobbyists. Pro was designed to target larger teams and the features they would need.
Inspeqtor compares itself to monit, god, supervisord, etc, but it looks like it only handles the monitoring of processes and not stop/start/restart, correct? It seems like it would be difficult to decouple those when we use monit for things like "if mem > 200m for 2 cycles then restart".
Anyways, it looks simple and I'm looking forward to it maturing. It will be nice to template and deploy via Ansible. I'm interested in monitoring PostgreSQL, Tomcat, etc...
Curious how you plan on managing a pro version of the product when the free version is open source. Will you just be rejecting pull requests which add features which are in the pro version? Given that the code is licensed GPL, this seems to be inviting a fork which will have additional features which would otherwise be restricted to the pro version.
People are welcome to fork and add their own features. They will need to support and maintain their features just like me. They will need to pull in upstream changes or their fork will rapidly age.
I target Inspeqtor Pro at teams and businesses with a real budget. They want a supported, pre-packaged product that solves their problem. If someone is willing to find and use some other person's fork, they were probably never going to pay for the Pro product in the first place and therefore there's little to no real competition here.
Would I reject PRs? Quite possibly; that seems super passive-aggressive to me. It would be more polite to open an issue first and discuss the situation.
I wasn't suggesting the case where someone explicitly does all the work and opens a PR which implements a feature of the pro version. I was moreso considering someone who had implemented something that was on the roadmap for the pro version. In either case, it's reasonable to say you would reject PRs.
I'm just wondering how governance of the project works. I assume you're already dealing with the same sort of thing with Sidekiq. I just find this sort of business model interesting since the more common approach seems to be providing hosting or priority support.
Yep, It's my job to communicate a vision for the product: what types of features are Pro, which are OSS. Right now my rule of thumb is "team" or collaboration features are Pro, the rest is OSS. Yes, I would close PRs if they provide more enterprise-focused features that I wanted to sell but not before chatting with the submitter and seeing if there was a common ground or some feature subset which could be open sourced.
Couldn't help but notice that the config file syntax is almost exactly like Monit. Inspeqtor's definitely is more concise and easier to read (and probably write), was Monit an influence in designing this tool?
I only provide LTS binaries since that's what most people run in production.
You can change your distro name to be precise or trusty in the packagecloud repo in /etc/apt/sources.list.d. It's a Go binary so it doesn't depend on anything distro-specific.
