Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inspeqtor: easy application infrastructure monitoring

mikeperham.com

Post reply on HN
Print view View original

11–20 of 21 posts

Re: Inspeqtor: easy application infrastructure monitoring

#11

Post by mperham »

pitr wrote: post #4

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 altoge…

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.

Re: Inspeqtor: easy application infrastructure monitoring

#12

Post by michaelmior »

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.

Re: Inspeqtor: easy application infrastructure monitoring

#13

Post by mperham »

michaelmior wrote: post #12

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.

That's a natural question.

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.

Re: Inspeqtor: easy application infrastructure monitoring

#14

Post by sbarre »

mperham wrote: post #9
sbarre wrote: post #7

I get "Unable to locate package inspeqtor" when trying to install on Ubuntu 13.10. The docs specifically say "12.04 and 14.04" but also "really any Debian system using Upstart". Is 13.10 not supported?

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.

Great, thanks!

Re: Inspeqtor: easy application infrastructure monitoring

#15

Post by skrebbel »

mperham wrote: post #13
michaelmior wrote: post #12

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.

That's a natural question. 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…

Good points, but you didn't actually answer the question.

Will you reject pull requests that compete with Pro features?

Re: Inspeqtor: easy application infrastructure monitoring

#16

Post by mperham »

michaelmior wrote: post #12

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.

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.

Re: Inspeqtor: easy application infrastructure monitoring

#17

Post by zrail »

pitr wrote: post #6
zrail wrote: post #5

Earlier quoted context omitted.

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: https://github.com/mperham/inspeqtor/blob/89151…

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 creati…

See mperham's reply here: https://news.ycombinator.com/item?id=8401372

Re: Inspeqtor: easy application infrastructure monitoring

#18

Post by [deleted] »

mperham wrote: post #16
michaelmior wrote: post #12

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.

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.

[deleted]

Re: Inspeqtor: easy application infrastructure monitoring

#19

Post by michaelmior »

mperham wrote: post #16
michaelmior wrote: post #12

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.

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.

Re: Inspeqtor: easy application infrastructure monitoring

#20

Post by mperham »

michaelmior wrote: post #19
mperham wrote: post #16

Earlier quoted context omitted.

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 w…

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.
Post reply on HN