solved Marketplace updates

alt=
DannyA
@dannya
9 years ago
584 posts
With acp, you can't update your modules if your core is behind. So I recently updated the core from 5.2.37 to 5.2.41. It took us a while, and we didn't get to update the other modules before 5.3 beta came out. I don't want to install the beta yet. How can I update the other modules without updating the core to a beta release?
updated by @dannya: 02/17/16 11:18:54PM
brian
@brian
9 years ago
10,148 posts
DannyA:
With acp, you can't update your modules if your core is behind. So I recently updated the core from 5.2.37 to 5.2.41. It took us a while, and we didn't get to update the other modules before 5.3 beta came out. I don't want to install the beta yet. How can I update the other modules without updating the core to a beta release?

You can update to new module releases without being on the beta core - just make sure the BETA channel is NOT active in the Marketplace -> Tools -> Release channels section, or you'll always be prompted to update to the beta core first.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
alt=
DannyA
@dannya
9 years ago
584 posts
Got it. thanks.
alt=
DannyA
@dannya
9 years ago
584 posts
Trying to update the cloud skin but it says I have no license, even though I purchased the cloud bundle. I think it's maybe because I got the bundle when it was still in beta
brian
@brian
9 years ago
10,148 posts
DannyA:
Trying to update the cloud skin but it says I have no license, even though I purchased the cloud bundle. I think it's maybe because I got the bundle when it was still in beta

I'm not sure what server you were trying to update - I added it to your "dev" server. Note that all JR modules/skins are licensed for 2 servers.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
alt=
DannyA
@dannya
9 years ago
584 posts
Thanks. Not sure why it popped up now. It's been on there for a while and never asked me before.

I'm not sure how much it costs, but it should probably be free. We already have to pay for the respective cloud module. The skin just help keep the interface clean. e.g. we already have to pay for the conversion worker running on another server, it's tough to jusify doubling the price on each server just to have a clean landing page.
brian
@brian
9 years ago
10,148 posts
DannyA:
I'm not sure how much it costs, but it should probably be free. We already have to pay for the respective cloud module. The skin just help keep the interface clean. e.g. we already have to pay for the conversion worker running on another server, it's tough to jusify doubling the price on each server just to have a clean landing page.

It's part of the bundle, which seems to be the way users purchase the cloud modules. My worry with making it free is that "normal" JR sites will download it and install it and wonder why it does not support any of the "regular" JR stuff. I'm 100% certain that would happen.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
alt=
DannyA
@dannya
9 years ago
584 posts
I think its fine to pay for it once as part of the bundle. It just the other servers in the cloud don't need the whole bundle. Usually it's just one or two cloud modules. My immediate concern is the conversion workers. Typically, a encoding/transcoding worker should be very lean. A quad core server is only processing a small number of jobs simultaneously. If you are processing large files, this means you will need to have many servers ready to go to handle spikes. To build a cluster of conversion workers, not only do you need a full jamroom install, but also multiple cloud modules. You're looking at $100+ to run ffmpeg. Adding another $29 for each just add insult to injury.

I know you'll suggest getting the monthly "unlimited license" package. But by pricing it so high, that's really the only option. The clients really need to be much much cheaper.

As for the skin confusion, you could just make it clear that it is intended for cloud servers and not the main app. They'll find out very quickly that its not.

Just my $.02
brian
@brian
9 years ago
10,148 posts
DannyA:
I know you'll suggest getting the monthly "unlimited license" package. But by pricing it so high, that's really the only option. The clients really need to be much much cheaper.

Really? You'll have to forgive me, but as a software developer I've never understood why site owners undervalue software so much. I'm certain your AWS monthly bill is much, much higher than $49 - and yet without Jamroom it wouldn't do you a thing but sit there and cost you money. The time and energy is in JR. AWS doesn't give a rip about your business.

Of course everyone wants everything to be free all the time (and supported well, out of hours, bugs fixed fast, etc.) but it costs money to do that.

I know it's just my opinion, and what you're saying isn't the first time I have heard it, but I just have never understood that position.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net
alt=
DannyA
@dannya
9 years ago
584 posts
Because the cost of code does not increase as my usage scales. It's a one time sunk cost.

Amazon has recurring cost every month because you are
1. Paying for facilities
2. amortizing cost of hardware
3. Bandwidth (and the infrastructure to support it)
4. People to administer it
Basically, there is an ongoing cost to them an the more you use, the more it costs them as well.

Software on the other hand is a once time cost (putting aside support and future development).

Lets say it to 10 hours to develop that skin; its pretty bare bones. Once you wrote it, it's done. If the time you invested was worth, say, $400, then you need to sell 14 copies to before you start making a profit. Every copy after that is pure profit. You can sell 1000 copies and its still only 10 hours you put it. Pretty good product.

On the other hand, look at it from my side. If I'm going to deploy 1 cloud server, $29 is not a big deal. If I need to put this on every cloud server its going to cost me more and more. Any thing over 13 servers, It would make more sense to develop it myself.

In a service oriented cloud architecture, where you distribute tasks across many many servers it is not unlikely that you could deploy thousands of servers, even for short periods of time. This is the value of cloud and what enables you to scale. However, you are adding a cost that makes it uneconomical to scale to a product that is intended to help you scale.

Another way to put it is that you are taking something that had a fixed cost to produce but increases in cost as you use it. In that case it's better to write my own skin or risk paying thousands of dollars for of something that has a one time fixed cost.

I don't purport things should be free, just reasonably priced. This pricing model is not appropriate for its intended use. It does not cost you any more time or energy if I deploy the skin on one server or 10000 servers.

Hope that helps.
brian
@brian
9 years ago
10,148 posts
DannyA:
Because the cost of code does not increase as my usage scales. It's a one time sunk cost.

Amazon has recurring cost every month because you are
1. Paying for facilities
2. amortizing cost of hardware
3. Bandwidth (and the infrastructure to support it)
4. People to administer it
Basically, there is an ongoing cost to them an the more you use, the more it costs them as well.

Software on the other hand is a once time cost (putting aside support and future development).

Lets say it to 10 hours to develop that skin; its pretty bare bones. Once you wrote it, it's done. If the time you invested was worth, say, $400, then you need to sell 14 copies to before you start making a profit. Every copy after that is pure profit. You can sell 1000 copies and its still only 10 hours you put it. Pretty good product.

It doesn't work this way - you even say so yourself - "(putting aside support and future development)".

Quote:
On the other hand, look at it from my side. If I'm going to deploy 1 cloud server, $29 is not a big deal. If I need to put this on every cloud server its going to cost me more and more. Any thing over 13 servers, It would make more sense to develop it myself.

In a service oriented cloud architecture, where you distribute tasks across many many servers it is not unlikely that you could deploy thousands of servers, even for short periods of time. This is the value of cloud and what enables you to scale. However, you are adding a cost that makes it uneconomical to scale to a product that is intended to help you scale.

Another way to put it is that you are taking something that had a fixed cost to produce but increases in cost as you use it. In that case it's better to write my own skin or risk paying thousands of dollars for of something that has a one time fixed cost.

I don't purport things should be free, just reasonably priced. This pricing model is not appropriate for its intended use. It does not cost you any more time or energy if I deploy the skin on one server or 10000 servers.

Hope that helps.

Jamroom is reasonably priced - in fact it is super cheap. If you went out and hired a developer to try and recreate Jamroom for you, the cost would be orders of magnitude larger than what you'd ever pay for Jamroom - even if you DID scale much larger.

Nothing you've said here refutes my point in any way though - basically what you are saying is that you do not feel Jamroom (and the ongoing support, updates and features) you get is worth $49 a month - even though you've decided to build your entire business on it. If you do end up spinning up "thousands of servers" then it certainly would be the cheapest way to go, but I won't try to help you save money any longer - if you want to purchase the Cloud Bundle every time you need it I won't stop you :)

I do however find it ironic that you justify the support you get from AWS as being worth the money, but history has shown me that when you encounter a server issue they're not helping you at all - instead you ask us. How about this - the next time you have a question on how Apache should be setup, or how Postfix should be setup - contact AWS - let's see how far out of their way they go to help you with an issue that's not part of what they support.

Anyway - that's just my opinion, and I don't make it habit to debate with customers :)


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

updated by @brian: 11/18/15 07:12:56AM
alt=
DannyA
@dannya
9 years ago
584 posts
Like I said, I put support aside. And I'm happy to pay for support. That too is not based on how many servers I have. For the most part, I think Jamroom is an great value. I think I've shown my support by buying almost every release and module over the last 10 years; since version 3. The pricing for a single server is very reasonable and you guys do a good job supporting people despite a small team. However, I have also spent thousands for developer time trying to figure out stuff because of lack of documentation. Granted, single server install is your target market.

I'm just telling you, as a customer, and as the former product manager of the largest open source video platform on the market, the pricing of the cloud modules is not affordable for its intended use. Cloud services are designed to be deployed on many many servers. Your cost per server to run a microservice does not match the development cost. Like I said, the cost to develop it is the same weather I run it on 1 or 1000 servers. I personally think, the server cloud apps should cost money, and the clients/workers should be free. This allows people to scale at a reasonable cost. Again, think of the use case. If I need to deploy 1000 conversion workers, how much would this cost?

Again, just my opinion. But I can tell you I'd sooner develop my own skin than pay for $29 to put a skin on each conversion worker. I can't afford that. Appreciate the debate though. At least you care enough to do so.
brian
@brian
9 years ago
10,148 posts
Sure - I want to be sure you feel like you're getting a good deal for JR.

My experience has shown that more "advanced" use cases for JR (such as the cloud modules) almost always result in more support resources having to be allocated to those users, so we try to price things accordingly. Right now we only have a handful of sites that are actively using (or planning) to use the cloud modules, since by far the majority of our customers are single server, so I appreciate the feedback.

As it grows and evolves we'll of course revisit pricing, features and support and see if makes sense to change things.

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Tags