I don’t update the gemfile very often, maybe like once a week, so I am actually not concerned about the lambda gems being outdated but every time I deploy it runs the rsync -a --links command. This burns through my credits even though its a small edit with no gem updates. Is there a way to optimize and use a cache or run only if gems are updated?
To be fully transparent, this is part of the plan to ensure that Jets has a sustainable business model. So don’t think will add a way to optimize this. Been trying to figure out how to support Jets. The open-source model is tough with very few Patreon donations. Would like to stay incentivized and give Jets a chance to be properly maintained, supported, and healthy. It also benefits companies and teams out there that use and rely on Jets to know that it’'ll be around for the long haul.
That being said, if you have an open-source project, you can email it to contact@boltops.com It may qualify for free downloads.
For sure. I completely understand.
I am not against the paid model— I just don’t think its necessary to rsync every time I deploy. Sometimes it’s a simple hotfix or some small formatting change.
Just FYI, I was a bit shocked at the pricing as I was expecting something like NPM and at least less than what we pay for GitHub which has its own package service. It was a warning flag for us. Do you still see the long-term development and growth of Jets?
1 Like
Often, have seen companies and services start off with very low attractive pricing, and then they raise prices later. Prefer to be more upfront.
Context also matters. It’s worth considering the cost of an engineer to build and maintain things. Engineering time is precious. Instead, it’s often better to spend time building product that drives value to your business.
RE: Do you still see the long-term development and growth of Jets?
It’s a labor of love. It’s growing, and would like to see it continue to. Funding is key to that. You and others can help it grow by encouraging companies to purchase the paid plans. Of course, no sweat either way. As things scale, can re-evaluate pricing.
I was initially confused by this conversation but just updated jets to see if it would fix a bug I was running into and was met with the requirement to sign up at serverless gems. I happily signed up and would love to support what you’re building here as it shows a lot of promise for some personal projects as well as some professional projects. After looking a little closer, I was a little disappointed that one deploy burned through 6 of my 30 available credits and I agree with @albanda in that, while I support a paid model completely if there’s any way to do so, the pricing caught me a little off guard. Your point on context certainly makes sense and is totally valid - at $50/month it’s less than an engineer - but are there any sort of promises / sla’s that bugs will be fixed quickly or that development will continue to progress over time? I almost feel like the price point is a show stopper as I’m testing Jets to see what is capable but would have trouble getting it off of the ground if can’t really test what is feasible without having to pony up some cash.
Again, totally understand the need for development to be sustainable and you deserve to be paid for your efforts - you’ve obviously put a lot of time into this and all of your tools but can’t help but wonder if the barrier to entry might be a little steep for someone who’s just trying to get started 
Would love to continue to support Jets, and you, however I can. Thanks for all for the hard work so far.
RE: Enough time to try it out.
Can provide coupons for more time to try things out. Letting you and anyone know that they can email contact@boltops.com for a coupon for the first month free. Title it: “Serverless Gems Free Month”
That’s plenty of time to try unlimited deploys. If you cancel before the first month ends, you won’t get charged monthly. Additionally, you’ll still have the free quota after the cancellation. Will improve the coupon process in time.
RE: SLA
Working on setting this up. Even though companies have already subscribed without it, still want to provide an SLA regardless. Think it’ll be focus on silver plans and up. As things evolve, can adjust the SLA accordingly.
That’s great @tung, I appreciate the effort and believe it’s a great place to start. Honestly, I’ve loved everything about Jets so far and have become quite a fan. I’m still learning my way around but will certainly look to support your efforts in any way I can! Very glad to hear you’ve been getting some companies signed up too.
Keep up the great work. Cheers
Hi @tung,
This caught me off-guard. I don’t have anything against supporting the project with money, but the model seems harsh and may scare away new and existing users.
My main concern is the risk management of the project maintenance. I manage it by maintaining control over the dependencies. This is one of the reasons why everyone uses open-source. If there’s a part that we can’t replace with equivalent, the risk rises. If we can’t look into what is being distributed as a dependency, the risk rises. If somebody would compromise your gem server, how would I know? If your service is about to go down, how can I replace it without risking my projects’ consistency?
Do you consider making this project open? A great example is sentry.io, where you can set up on your own server, but a big part of the users will choose a paid, hosted version, knowing that they’re safe to switch if needed.
Also, the way of burning the credits feels to be a little unfair. I understand that it may be hard to find a good business model here.
I really like the business model of Sidekiq https://sidekiq.org/products/pro.html, where you get more if you purchase the pro version. This does not affect how the free version works at all. And if a company uses Sidekiq to the level where they earn from it and need more than the free version offers, they pay for it.
By the way, how Jets 2.x handled the binary dependencies problem back then?
Edit: I think one of the problems here might be the way Jets is communicating that there’s a service that provides binaries. It’s enabled by default, and then it’s breaking the deployment procedure. I don’t know if I need it or not. It should work the opposite - if my project need binaries, I should be introduced to your binaries distribution service.
Studied a few open-source business models. Making money with open source can be hard to achieve. Trying to figure it out. The current model is based on DockerHub pull limits. Companies are currently signing up 
Seeing where it’ll go and can re-evaluate over time.
The gem building system is a core part of the business model. It would also be a decent effort to open source. There are no current plans to open-source it. For security, the system is built on AWS - pretty well versed in this area. If enough customers request it, can handle concerns with 3rd party audit, possibly SOC2. It may make sense for other future business areas also. Will re-evaluate over time.
There are options already for those who wish to maintain the binary dependencies themselves:
- Disable ServerlessGems and build and manage the custom lambda layer. Most serverless frameworks don’t provide binary support like ServerlessGems. Users manage their dependencies with custom lambda layers.
- Use or create equivalent gems that are not binary and provide the same features.
- Open Source projects may qualify for a free unlimited plan.
For #1, here are the docs:
- https://rubyonjets.com/docs/serverlessgems/
- https://rubyonjets.com/docs/extras/custom-lambda-layers/
Also, released Jets v3.0.4 with an update to the messaging that provides the same links above.