But essentially you want versions of their software? or you want them to host old versions of their software? As a company its not in their best interest. The reason it is cloud based is so they can push out changes to the masses and know their users are all on the same version. This is really important since all the features aren’t going to be in the initial release. Im confused by the need to"backup that glowforge". The firmware probably won’t change much once its release. Since the motion plan is coming from the cloud all the unit itself has to do is execute it. And if there firmware does change you would have to install it manually. Everything else is handled by them in the cloud.
I think the question was brought up before to have a Local Cloud/Server to run the Glowforge. @dan has basically said its possible but not currently a priority. The quote is below.
On the flip side, if you are willing to do the work for free, maybe @dan will change his mind. 
But I wouldn’t be surprised if there are other issues to get this working that they just don’t have the bandwidth to deal with as of yet.
2 Likes
I feel one glaring issue has not been discussed: security/copyright. As a company it is upto glowforge to maintain it’s security, privacy and it is their “right” to protect themselves from breaches of copyright. Most modern hardware/companies do this via updates(but I don’t need to tell you, this is for less savvy guys) as well as adding/adjusting content services. Due to this reason I think their trusty techies/lawyers would advise against it even if 1% of users wanted either glowforge maintained images of old versions or to public ally released images(that may have bugs/exploits)
Sorry that it’s not what you want but I doubt this will happen in the next 3+ years, their long term plan will likely evolve and might enable this sort of functionality.
Software, in many different versions bugs and all, is traditionally desktop side and archived as a cd with an installer. I should not neglect to mention that it is normally a binary blob at that point, obfuscating the operation and to reverse engineer it one must intentionally and knowingly go out of the way therefore the law protects the company’s interests. If the core of the server side software can come in this form, that is fine with me. If it is php or something that is basically open source if anyone else gets their hands on it, I still have hope since the firmware was put under the GPL.
In addition, GlowForge is not a software company. Is their plan to perpetually sell more and more machines to pay for the bandwidth and cloud computing of all machines sold up to the current time? If this long term plan sounds familiar, look up the definition of a ponzi scheme. I think GlowForge could look at the 22 year old, billion dollar enterprise that is built entirely on giving away free software. RedHat’s model is selling support subscriptions and certifications.
The GlowForge cloud will inevitably get costly, just not on a per-user basis. They could provide support only for those using the GlowForge cloud, latest version of the software, etc, and several years of free access for each machine sold. After that, a very reasonable subscription (rough estimate around $15-$20/year/GlowForge) would cover their bandwidth and computing costs for the user to have access to the latest release, the GlowForge cloud, phone support for said software, etc. In this way the machines profit margin can perpetually pay for development of new machines, and the software could perpetually pay for advances to the software. Otherwise growth of the software requirements will inevitably consume the entirety of the machine’s profit margin. This is a fact that was not previously seen because in a traditional model a company would not need to shoulder the cost of electricity, bandwidth, cooling etc for running the software of a long lasting device - once a piece of software was no longer affordable based on the number of machines being sold, they just end support for it without the consumer losing the ability to use the product.
If anyone believes the company is going to make all of it’s profit through selling GF units then I have a bridge in NY to sell you. Obviously I’m guessing here but there will be profit from, selling the H/W, potential H/W uprgrades, selling unlock codes for previously unannounced features, materials sales, catalog sales, probably subscriptions to some other services. Their stated intent is not to charge for server time to the initial backers for the original features. That’s great. You want more, you might have to pay for it. If you get GF 2.0, maybe you’ll have to have a subscription service. I know what I paid for and am perfectly fine with that. Anything additional, I might have to pony up some more cash. Such is the nature of every profitable business.
4 Likes
@dan has already stated they will not charge for “currently announced” features. I took this to mean that there are more features that they haven’t announced yet that will have to be paid for, either by subscription or per feature or something. I also wouldn’t be surprised if there is a small fee for selling designs in the Design Catalog (similar to etsy).
But more importantly, @rpegg, tell me about this bridge. 
2 Likes
A bridge in NY you say? I could do with one of those, a bridge from the UK to NY would be better 
As much as I would like to say that Glowforge exists to put a 3D laser printer on every desktop, I grudgingly take off my rose-colored glasses and know that the economic model that gives the best return will win the day. What the future of the cloud model will bring in terms of subscriptions, what future iterations of the product require more investment, I don’t know. All will lead to comodification of product and services. That’s ok. For the immediate future I see the Glowforge experience to be end-user driven and that will make for some wonderful stuff and happy people.
This just means we want to be careful not to promise anything other than what we have solid plans to deliver.
6 Likes
Hi Dan,
Thanks for visiting!
Any thoughts on the home archiving or data security and the eventually unsustainable model of hardware-pays-for-software? I know I for one wouldn’t want to have dropped a couple thou just to to sit through an add for every model I want to upload.
I will restate a few points.
First, what will you do long term? Cloud computing costs money, more users means it costs more money, and eventually your cloud costs will not fit within the profit margin of your hardware sales. In other words you may need to split your software and hardware budgets and get a revenue stream on both sides, but you cannot just brick the machine of a user who does not want to pay for their portion of your cloud.
To address this and other concerns listed below, I proposed something.
I am not asking for:
1: Custom firmware
2: Desktop support
3: Development of offline support
4: Use of unofficially developed software
5: Almost any time from Glowforge employees
At simplest I am asking for a file that, from the existing server(s) hosting the live CAM, motion planning, and other pieces, could be made in about 2 minutes given a script (which I would be happy to write). It would be a list of installed libraries, kernel version, and a copy of the necessary code and configs to restore the server in case of an outage. In other words, your backup if you have one.
It would need to allow someone with enough experience setting up servers to create an environment where the backup could be restored thereby achieving:
1: Result consistency via access to archived “same-as-the-first-time-I-printed-this” versions of the GlowForge cloud
2: Data security/enterprise options/local hosting potential
3: Third party solutions for the cloud pricing problem ( if enough users don’t like your cloud pricing they would have options which you obviously don’t have to support and you could focus on the software/hardware not this part. I wouldn’t want ad-supported but I’m sure a third party would be happy to provide it and some users would be ok with that. )
There may be hurdles, some already mentioned and others like the potential use of certificate pinning, but even before the difficulty is fully assessed I am curious about your thoughts on everything above. Any chance on archived versions of the cloud or other approaches to the three points it may achieve?
1 Like
To your question, we budgeted for the cloud utilization over the lifetime of the device at the start, so we can afford to run the servers for the machines we sell for many, many years to come.
Regarding your request - understood. No plans but we’ll let you know if anything changes. It sounds like this is really important to you, so if our current plans don’t meet your needs, mail support@glowforge.com and we’ll regretfully issue a prompt refund.
1 Like
I won’t be asking for a refund, the GlowForge is far more important to me than software versioning or local cloud. I simply find irony that cloud apps, app stores, and subscriptions decrease the people’s ability to own their copy of software while at the same time they are gaining the ability to manufacture more and more physical things.
In addition, I have am intrigued by any difficulty more so than deterred by it - I sometimes spin up several custom servers on any given day so for me the option to do a local GlowForge cloud would definitely be utilized.
Anyway, thank you for your answer. I hope you consider the options again in the future, but I would far prefer not causing delays in getting the first shipments out!
I think it would be pretty cool to be able to host the software myself. I don’t know what kind if cloud resources it takes to do the processing for the GF (it would be an interesting statistic to say the least), but I like to look at the worst case.
If something were to happen and GF were to have to close their doors (I don’t suspect that will be happening, but just for the sake of argument), what would the plan be for all of the owners of the GF at that point? If it resides on the cloud and the cloud goes poof, do we all own big paperweights? Or what about the scenarios where people don’t have a strong Internet connection, or are limited by bandwidth. Are there any details about the bandwidth requirement or amount of data transferred per job on average?
Luckily I think most of us don’t have to deal with those situations. I am still a geek, though, with a rack cabinet of servers in my house running VM’s (part for work, part for learning) and think it would be pretty cool from an academic point of view to create a ‘private cloud’ that can handle the processing at some point down the road. Really what you are doing is an interesting use case I think, so I suspect others will want to explore it as well.
One of the points I believe @SolesUrsa brought up was that different versions of the cloud-based motion planning and layout might result in different results from one version to another, as Glowforge evolves everything.
[feature request] Would it be feasible to allow customers to choose the version trunk of the cloud software they use, tied to their accounts? Similar to allowing users to choose whether or not to go with the git master trunk, the nightly release, or the last stable version? They could pick it in their account preferences when they sign into the cloud.
That was talked about here.
The make magazine article discussed at Make Magazine review of Glowforge had a great image for me to illustrate my point with a couple of edits.
For a hobbyist example, lets say you are making a waterfall as part of a larger design and you ran a couple tests on the spare part of your board getting the result on the left. You finish the rest of the design, but during that time the cloud team installed their upgrade and the board you had carefully picked out for your engraved art ends up with the waterfall on the right. No ‘mist’ at the bottom.
In an example with the spirit of the Glowforge paying for itself, how about making signs for a local bakery’s display case? You make an engraved mahogany sign for each of the products – from bear claws and danishes to quiches and cookies. The bakery forgot to mention their croissants, so you tell the bakery it will be a simple 30 mintues of labor and $10 of additional material. You load up your template, change the text, and hit go. Instead of the top example, you get the second one without the q-tip look. You can redo your template to trying to match the other 12 signs, but you’d need to get one sign back from the bakery for reference and most likely you would never get a perfect match - you probably have to reprint all of the signs and either take a loss or explain a very surprising bill to the bakery (and the next time they need a sign they’ll get the full set remade again – by someone else).
As the Make article said, “The good news is that these are all software problems that the team can fix while they are still building your unit.” In other words the best intentions would be behind the software update, yet the whole point of the updates is to change how the Glowforge works. That is, the software team is changing every user’s production line without consultation. There’s no way the users could go back or even know how far they would need to go back.
Obviously I’ve though a bit about it all. Before launch, it might be good to make sure each recorded job includes which version of the cloud was used to produce it. Later, on the user interface side, let a user group jobs. There’s two goals: be as consistent as possible(historic software), or to be as close to the design as the Glowforge can acheive(latest software). If they add a job to the group and the current software is different from previous jobs in the group, offer the user the latest software or the software that was used for the other jobs in the group.
There are a couple remaining problems though. If the user tries the latest sofware at different times there could ultimately be many forks to pick from – realistically it narrows the list of possibilities but in theory they could have produced a job from the group during every single version of the software to have ever existed. Possibly offer three: the first used version, the most used version, and the latest version.
Another remaining problem is safety – if a version of the software is unsafe for the forge or the user, can you still offer it? In this case maybe the oldest software you offer is the oldest safety update. Maybe you offer the original version with a disclaimer and end user agreement to expose their forge or self to the dangers (and in the case it makes sense maybe void the warranty). In the latter case the list of options gets up to 4: the first version used by jobs in the job group(may or may not require disclaimer), the most used version(may or may not require disclaimer), the oldest safe version, or the latest version.
I think if any user uploads the exact same design, they expect a machine to produce the exact same result. I’m not going to request a refund over it – I do prefer 0.3 from 0.1+0.2 instead of 0.30000000000000004, but if something works for me I’d like to be able to make sure it will always work.
5 Likes
It’s my understanding that issues like fine tuning the focus with the camera lens, engraving, etc. are going to be finalized before the production units ship. So that part isn’t going to change after the production units go out.
The Make Magazine article was written based on testing of one of the Pre-Release units. The changes to the software are being made now, before the production units ship, so yeah, there are going to be differences between those and what they will see once they get their personal units.
Unless you signed up for Beta testing and are trying to use one of the Pre-Release units for a business enterprise, it shouldn’t be an issue.
Makergear sends a letter to each of the Pre-Release testers that they select, explaining exactly what the model that they receive can and can’t do yet. So they tell you if it’s limited in some way.
They will be taking the Pre-Release units back and replacing them with Production units when they are ready to be shipped. 
1 Like
This is a recurring issue in software. While not common, you’ll see comments in code like, “the following is a workaround for the blah, blah issue in v1.2.1 of something.” If that issue is ever fixed you may need to update the code by deleting the workaround. Same thing when a library is updated and backwards compatibility is not properly maintained or is simply abandoned. Having a single version in the cloud versus multiple forked version has its trade-offs, but I’d still go with the single version for the glowforge. Which is not normal for me. When presented the choice between living with the bugs I know and upgrading to the bugs I have yet to find, I almost always go with the former. For the super users, as long as the release notes are detailed you’ll be able to catch this issue before it ruins any material. Unless of course they fixed a bug that you thought was a feature - then you’ll be surprised.
As regards your concerns about safety, I don’t think it is reasonable to expect that Glowforge would leave a safety bug in the software just so some feature(s) would remain available. The advantage to a cloud based system is that if a safety problem is discovered you can immediately roll everyone back to the last safe version. If there is no known safe version you can brick every machine until the safety issue is corrected.
2 Likes