HangFire.Redis incompatible with ServiceStack 4.0

[peters]

Unable to install if using ServiceStack.Redis.

It's no big deal for us since we can just fallback to Sql Azure but this should be fixed anyway.

[odinserj]

Yep, and since ServiceStack 4.0 uses another licensing strategy, there should be both support for 3.x and 4.x versions. Or maybe Redis storage should use StackExchange.Redis library instead. I'll choose the solution, but a bit later.

[Tazer]

Any plans on making the switch soon ?

[Caldas]

ServiceStack 4 has a different license. I don't think it's a good idea to use it

-----Mensagem Original-----
De: "Patrik" notifications@github.com
Enviada em: ‎26/‎08/‎2014 11:49
Para: "HangfireIO/Hangfire" Hangfire@noreply.github.com
Assunto: Re: [Hangfire] HangFire.Redis incompatible with ServiceStack 4.0(#122)

Any plans on making the switch soon ?
—
Reply to this email directly or view it on GitHub.

[Tazer]

@Caldas I'm with you on that,

I was referring to switching to StackExchange.Redis

[ghuntley]

Hmm. Ran into this today for now just using SQL Azure as workaround. Have SS license and I'm using SSv4.Redis but if you need to go StackExchange.Redis then either way. - Subscribing.

[kieranbenton]

I would also +1 for using StackExchange.Redis, its had some initial teething problems but it is now very stable and very fast, as well as having barely any dependencies.

Anything we can do to help @odinserj?

[TheCloudlessSky]

👍 For the switch. I've been porting my projects to use StackExchange.Redis.

I pulled down Hangfire to see if I could start ripping it apart to use StackExchange.Redis. The most glaring problem to port it over will be the fact that currently Hangfire uses blocking pop/push commands, which StackExchange.Redis doesn't support because of multiplexing.

I'd be glad to help port this over if we can collectively decide how to implement this.

[sjwoodard]

@TheCloudlessSky, I'm able to help as well.

[sqmgh]

I haven't gone through all the code to see for certain, but if it's only using the blocking pop/push to wait for the next item to process, why not use pub/sub a method similar to what is described on the linked StackExchange.Redis page?

I think that for licensing reasons a StackExchange version is worth having. Even if it's only in addition to the ServiceStack one.

[kieranbenton]

Sounds reasonable to me, is there any appetite to getting this done? I'd
happily lend some time to this.

On 15 October 2014 21:02, sqmgh notifications@github.com wrote:

I haven't gone through all the code to see for certain, but if it's only
using the blocking pop/push to wait for the next item to process, why not
use pub/sub a method similar to what is described on the linked
StackExchange.Redis page?

I think that for licensing reasons a StackExchange version is worth
having. Even if it's only in addition to the ServiceStack one.

—
Reply to this email directly or view it on GitHub
#122 (comment).

[sergeyzwezdin]

Does that means that if I use redis as a stroage for hangfire I have to pay for StackExchange?
@odinserj could you explain?

[TheCloudlessSky]

@sergun No, you shouldn't have to since the current version depends on ServiceStack.Redis < 4.0 packages which do not require a commercial license.

[sjwoodard]

Hangfire uses ServiceStack v3, which is under the BSD license. @sergun said "pay for StackExchange", but StackExchange, which is under the MIT license, is not used in Hangfire. Earlier in this thread we were discussing switching Hangfire from using ServiceStack to StackExchange, but I'm not sure what @odinserj thinks.

[sergeyzwezdin]

@TheCloudlessSky @sjwoodard Thanks for expanation guys.

Regarding migration to StackExchange — I'd completely agree with it. It would be better as for me :-)

[TheCloudlessSky]

@sjwoodard Sorry, yes, he did mean StackExchange. I've always found the the two have such similar names that dyslexia kicks in...:dizzy_face:

[odinserj]

This feature is implemented in a new version of Hangfire Redis library, you can look the details in this blog post.

Migration to StackExchange.Redis is unnecessary, and Hangfire.Pro.Redis uses ILMerge to internalize ServiceStack libraries to the assembly. Since there is no any dependency now, you can use any ServiceStack version in your project.

[TheCloudlessSky]

What the heck is up with .NET developers and commercializing their libraries and dropping support for things (ServiceStack, RavenDB, Hangfire etc)? The idea of FOSS seems to be lost in this community...

This is bad news, in my opinion. I don't disagree with you offering a commercial version (you should be getting paid for your hard work), but there are plenty of good reasons to move away from ServiceStack.Redis and keep the rest of the project FOSS. I'm either not going to use Hangfire or maintain a separate Redis library that uses StackExchange.Redis.

[odinserj]

@TheCloudlessSky, I've introduced commercialization to have a chance to support the project in a long-term. My life is not stable enough to regularly work on projects without any commercialization for a long time. Perhaps there are better solutions for Hangfire, but I don't see other ways that satisfy my project vision.

May be I'm not smart enough, maybe I have the wrong vision, but I think my decisions are acceptable, and I understand the consequences. It is also unclear for me, what do you exactly mean by the idea of FOSS (please use less abstractive wording). But I'm sure there will be no idea at all for a project with dropped support.

I'm either not going to use Hangfire or maintain a separate Redis library that uses StackExchange.Redis.

You do not offer any assistance, only criticize on an abstract level. So why we are talking about it?

[TheCloudlessSky]

Actually, I have very much offered to help (see above). I would be glad to
contribute to a free and open source (FOSS) version of Redis storage for
Hangfire. And it is probably what I will do. Check my profile, I maintain
several projects that use Redis as the storage.

Like I said, I'm not at all against you commercializing your work (offering
paid support). I just find the .NET community goes about it wrong (dropping
open source support for existing libraries and/or making them no longer
open source). It happened with RavenDB, ServiceStack and now Hangfire (and
I'm sure plenty of others). Its not the true definition of open source.

Anyways, I'm definitely capable and willing to port this with
StackExchange.Redis. Thanks!
On 2014-11-15 10:41 AM, "Sergey Odinokov" notifications@github.com wrote:

@TheCloudlessSky https://github.com/TheCloudlessSky, I've introduced
commercialization to have a chance to support the project in a long-term.
My life is not stable enough to regularly work on projects without any
commercialization for a long time. Perhaps there are better solutions for
Hangfire, but I don't see other ways that satisfy my project vision.

May be I'm not smart enough, maybe I have the wrong vision, but I think my
decisions are acceptable, and I understand the consequences. It is also
unclear for me, what do you exactly mean by the idea of FOSS (please use
less abstractive wording). But I'm sure there will be no idea at all for a
project with dropped support.

I'm either not going to use Hangfire or maintain a separate Redis library
that uses StackExchange.Redis.

You do not offer any assistance, only criticize on an abstract level. So
why we are talking about it?

—
Reply to this email directly or view it on GitHub
#122 (comment).

[odinserj]

I just find the .NET community goes about it wrong (dropping open source support for existing libraries and/or making them no longer open source). It happened with RavenDB, ServiceStack and now Hangfire (and I'm sure plenty of others). Its not the true definition of open source.

On the other hand, other open-source background job systems for .NET like Resque.NET, Linger, C# Resque, Roque, WebBackgrounder, Revalee, Burden, awesome Blue Collar, powerful Quartz.NET have low or very low activity (like other 95% OSS projects) and many of them may be considered dead. Open-source, but dead.

Open source is really hard. And I simply can't allow circumstances to destroy the work done. This is my first open-source project, and I consider the risk of project death is very high since the very beginning.

[devmondo]

if you have stuck with .Net enough you know that background tasks functionality and solutions are very hard or lacking and what @odinserj did is just amazing in terms of simplicity and stability and i for one support all the way his notion of commercialization of his product, i really dont believe in freemium model, if @odinserj spends 50 % of his daily time on working on Hangfire for free, where would he earn living from? if he wants to spend time on answering you, fix bug for you, add new awesome features, how much time he needs to spend on that ? plus if we look at other similar commercial .Net solution we would see that the price of Hangfire is reasonable, specially that the license gives you unlimited usage on servers and domains.

but with that being said i really wish @odinserj rethink the pricing model, 500 $ seems really steep, specially that now customers are like sheep falling for the cloud model and its pricing, specially something like Azure where it offers Hangfire functionality among mired of other integrated services for what looks like a cheap price.

if i may suggest the following

• 250 $ or 300 $ as subscription price
  -make it used on unlimited servers and domains
  -mention it works with ASP.Net Vnext on Linux and Mac
  -improve Docs and Samples

change the current subscription page details to reflect that clearly, as the current one you have to go through reading the large confusing (for poor souls like me) page.

Hangfire is a precious Gift to us given by @odinserj and the way it made my workflow simpler alone makes me pay to support the efforts.

[TheCloudlessSky]

@devmondo I think you've misunderstood what I'm arguing here. I'm not against letting @odinserj get paid for his work. I am against the .NET community not fully embracing open source. ServiceStack.Redis took a turn for the worse because of their licensing changes and dropping of true open source.

@odinserj We're still arguing about different things. I support you commercializing things such as support, "extra features", etc to get paid for what you're doing and keeping the project alive. But I am against you dropping support for a library that already exists as open source (or switching it over to a commercial library). I have never said open source was easy, but you're damaging the .NET open source community by dropping this library from open source.

[odinserj]

Hi, @devmondo. I'll be improving each part of the project, including the pricing page. It is hard for me too :) Regarding the pricing model – I thought about it for some monthes, and it suits current context.

@TheCloudlessSky,

you're damaging the .NET open source community

No, really?

[devmondo]

@odinserj long time i did not talk to you, i am a father now and barley can breath :)

regarding pricing, i wont argue much with you, you should get money and feel satisfied, but i suggest that Async, Continuation, Parallel features should be in the free version, and stuff like Performance Counters, Replication and Mission Critical features and urgent support should be in the pro.

why i am suggesting the above, because the way i see it, it is going to give you more marketing, as the more users will use it the more the word will spread, and as you know when users sites grow, they will need more enterprise features, and because they are using Hangfire already, they will naturally eventually pay for the pro and will not look for alternative solution

trust me this is how smart Americans do business, they are flexible and know how to lure customers in, while rest of us Russians, Asians and rest of the world sometimes do it all or nothing :)

besides i think that you will benefit more if you open a survey and user voice so us users will give you our opinion about features and pricing we are willing to pay for Pro, this will give you scientifically practical estimation of how people want to pay for your product and you will get more guarantee in terms of the best business model you should follow.

just my 2 Rubles :)

[ghuntley]

On 17 November 2014 23:35, devmondo notifications@github.com wrote:

regarding pricing, i wont argue much with you, you should get money and
feel satisfied, but i suggest that Async, Continuation, Parallel features
should be in the free version, and stuff like Performance Counters,
Replication and Mission Critical features and urgent support should be in
the pro.
Completely agree with above.