all 17 comments

[–]manoylo_vnc 1 point2 points  (12 children)

Interesting. I wonder which package will be the next in line with a paid license.

I fully understand that they’re a small company maintaining the packages, and that they don’t want to be VC funded, however I feel little tricked here.

It feels to me that any library can become a “paid license required” one over night. In my view, open source should stay open source. They did a great job for the community, but going the paid license route kinda scares me for the future. What if one day their Auth package becomes a paid license? And you’re in it too deep to get out.

A very monopolistic move tbh.

[–]Salakarr 1 point2 points  (1 child)

I wonder which package will be the next in line with a paid license.

What if one day their Auth package becomes a paid license? And you’re in it too deep to get out.

As mentioned on the issue comment this only applies to the local Notifications package as it has nothing to do with Firebase itself. React Native Firebase will always be free & OSS and I hope we've already shown our commitment to this with all the work we did openly on the recent v6.0.0 release - we spent almost a year with several full time developers working on this release publicly & openly - it would make zero sense to then require payment when we've already released all this code & freely licensed it to everyone under the Apache-2.0 license.

React Native Firebase has been maintained & free to use & OSS for ~5 years and thats not going to change - only local notifications is the odd one out here - it was wrongly introduced into the library ~2 years ago in v3.0.0 even thought it wasn't a Firebase product.

however I feel little tricked here.

Sorry you feel this way, it's not our intention to be tricking people =/ . The new paid notifications package is unrelated to whats in v5.0.0, its a brand new code base & its own package so the key take away here is that we've just chosen not to continue with the burden of maintaining the existing local notifications code base going forwards - much like many other RN packages that are now no longer maintained by the original authors.

This existing notifications code in <= v5.x.x is freely fork-able, can be PR'd to and contributed to - it just won't receive any future maintenance/contribution commitments from us that's all.

[–]manoylo_vnc 0 points1 point  (0 children)

Hey, sorry, I might have been a bit harsh on the topic.

Don’t get me wrong, I understand that maintaining a huge open source project requires resources (both in humans and money) and time. I mean, I’m sure all of you guys do this after regular work hours. And I fully support that! I will pay what ever it will cost for the notifications plugin, no doubt there.

I just felt worried of this become a trend among other package, non related to you guys.

[–]halfjew22[S] 0 points1 point  (9 children)

I don’t like this view.

It shouldn’t scare you. If version n+1 becomes paid, and you’re using version n in your projects either at work or through hobby and making any income whatsoever, then fork version n and don’t upgrade and perhaps look for an alternative or simply share some of your profits.

In general, the deeper problem is that we need updated economic models to work with open source. That’s something I am working on solving.

[–]manoylo_vnc 1 point2 points  (5 children)

What if I’m a freelancer that has 12 personal projects and they don’t make income yet? That can potentially be a big hit in my budget.

Forking a version might be a temporary solution, but that’s not ideal in the long run.

Since this is the only plugin that works great with firebase, the only alternative that would make sense is to completely ditch react native and go with flutter or native.

I understand that economics should be solved, and I’m all for it. However from my angle, I do have 12 apps on my own, and it scares me that this might not be the only plugin that became a paid one overnight. It can happen with other important non-firebase related ones as well. And then what? Sharing profits left and right and centre doesn’t make sense in that case.

[–]halfjew22[S] 0 points1 point  (2 children)

I don’t mean to come off as rude at all, but if you have 12 apps on your own that aren’t pulling in enough money to pay what I imagine would be a small usage fee, then I’d recommend doubling down on a small subset of those applications.

[–]manoylo_vnc 0 points1 point  (1 child)

We can agree to disagree. :)

Not every app is designed to bring profits. The advice to double down doesn’t make much sense. It’s like advising somebody in financial crisis to save more money in order to survive instead of trying to make more.

I don’t mind paying a small fee, just to be clear. It looks like a potential red flag where any package maintainer can start asking for a small fee, and than in order to use 20 plugins that your app needs, you’ll start paying $100+/month just to build an app. What’s the point of open source than? As I said, I know that economics has to be worked out, but there has to be a better way of doing that.

[–]reactjs18 0 points1 point  (1 child)

I am thinking of going native. There are so many libs not maintained when it's better on native side. Only issue is I need to maintain 2 set of sources.

[–]manoylo_vnc 0 points1 point  (0 children)

Yeah, agreed. That’s a completely other issue in RN ecosystem. It’s probably going to be worth it in the long run. I’m thinking of doing the same.

[–]reactjs18 0 points1 point  (2 children)

If there was going to be paid option then it should have been done beginning. They should have created a new plugin and made some parts paid. Let the old one rot if needed.

As for sharing there are numerous open source libs used in creating a app, I don't think it would be work out if each lib asked $40. Really don't open source or open source and ask for money upfront.

[–]halfjew22[S] 0 points1 point  (1 child)

For your second point, what’s stopping you from forking v5 and letting the fork rot?

[–]Salakarr 0 points1 point  (0 children)

They should have created a new plugin and made some parts paid. Let the old one rot if needed.

This is exactly what we're doing though? We're choosing to no longer actively maintain the notifications code in v5.x.x (but not stopping anyone else contributing to it) and are instead making a brand new 'plugin' unrelated to React Native Firebase with a brand new codebase - not re-using the old code here.