More thoughts about internet requirement


#1

I realize the topic of required internet access has been discussed at length on this forum, so I went ahead and searched through the past postings. I have a few thoughts that I don’t think have been brought up:

  1. We were all given an enthusiastic (and apparently irrevocable¹) guarantee that the firmware for the Glowforge would be released under the GPL “when it ships”. The Glowforge is now shipping, but I have not seen where the firmware was released. The Glowforge GitHub organization has no public repositories.
  2. Using the cloud for planning and motion calculations means that Glowforge Inc. knows exactly when and what I am cutting/engraving/printing. This means that, if served valid a government subpoena or warrant, Glowforge Inc. would have no choice but to hand that information over to the government. Even if I wasn’t doing anything my government wouldn’t like, if I was developing proprietary parts which were highly sensitive, the idea of uploading the exact instructions on how to make those parts to a service which I have no control over is a bit off-putting, to say the least. I haven’t seen any policy statement about how our data will be kept private and secure.
  3. Because these printers require internet access to remain useful, they may be rendered useless by the government at any moment, either intentionally or unintentionally. For example, during the Arab Spring, Egypt effectively cut off all routes to the internet outside of Egypt, which would have rendered devices like these entirely useless. Or, perhaps the government wants to prevent people from being able to manufacture things without government approval: they can simply block access to the servers and no one would then be able to use Glowforges.
  4. I haven’t read any details yet regarding the nature of the connection between the Glowforge device and the Glowforge cloud. If it is not protected with TLS, the designs that I am cutting could be intercepted or forged. I sincerely hope that all connections to the Glowforge cloud are properly encrypted and authenticated.
  5. I haven’t read any details yet regarding what mechanisms will be in place to prevent this device from becoming compromised by other devices on the network, or from a man-in-the-middle attack.
  6. I haven’t read any details yet on if this device can work with a proxy (like a HTTP proxy or a SOCKS proxy). This would be useful.

I also have a requests for a future “Pro” version:

  1. Please include an ethernet port.

¹ Quoting @dan: “There’s no backsies on that once we ship”


Cloud App Question
#2

excellent questions each worthy of discussion. regarding #2, dan has mentioned in the past their commitment to user privacy with a few points. so while i generally trust them, i agree it would be nice to see this in an explicit user policy.


#3

I have thought about the absence of an internet connection or of GF itself. Will my GF become a Glowbrick without either one these entities or will we be able to have local software?


#4

It will become a Glowbrick. They have said they would release the firmware so someone could write an interface for it. That requires three things. The firmware being released, which it hasn’t yet, and probably won’t be of Glowforge were to fold. You would need to apply the firmware to the Glowforge. The really big hurdle is someone developing an interface or drivers for it. This would probably be an open source project. Although open source projects can be impressive, they are usually slow to develop and buggy. If Glowforge is still tweaking their interface, and camera alignment, and autofocus, just imagine how log that would take in open source! I would not expect much more than simple Gcode functionality, and at best, nothing as good as the Muse software out of an open source project.


#5

What mad_macs said, but I think the chances of Glowforge folding before they get to the point of firmware release is incredibly slim. The other two points, however, make a :glowforge: open source interface a long shot. The fourth point for your consideration is that the laser tube is a custom part with a finite lifespan. Without replacement tubes what’s the point of developing an open source interface?

What they need to succeed is a large-ish customer base that semi-regularly uses their units. That their initial pre-order count was impressive and having owned a :glowforge: for three days now I am of the opinion that I will not be stuck with a Glowbrick Pro. Even if the development was impressively budget-busting and the BOM costs way out of control and somehow glowforge is mismanaged into the ground, as long as the machine works well (and I think it does) and there is a good sized base someone will probably come along, say, " I can fix this", buy the remains, and keep it going (repeat as necessary.)


#6

If GF don’t release the firmware then the simplest thing is to replace the electronics and run GRBL and Laserweb. Open source can outperform small companies if they are popular enough to attract more developers than a small company can afford.


#7

What would be cool is if Glowforge put all the backend code to run the glowforge into some sort of digital escrow beforehand, that would be released if the company ever went under, or sunsetted the service. That way we would all have some reasonable expectation of continuation of service should something happen


#8

Motion control is easy and nothing new. What they bring to the party is a good GUI and the vision stuff, which isn’t really working yet. I expect the vision stuff can be done with OpenCV and has a lot in common with the OpenPNP project.


#9

I seem to recall Dan saying that IF glowforge dissolved the firmware would be released.

The potential for the company to be sold and the new owner going to a subscription model is more likely than the company failing I think.


#10

(emphasis added)

It wasn’t an IF, it was a very distinct WHEN:

“here’s a commitment we’ll make right now: When we launch Glowforge, we’ll also release a copy of the firmware under GPL.” @dan

I’d say the Glowforge has been released. Wouldn’t you?


#11

I’d say I’d rather they focused on getting everyone their machines before getting this firmware out. If they could do it without affecting shipping an iota, fine. Of course, if that were true I think they would have done it.


#12

They’ve been very clear that while the machine is complete, everything else is still in a workable but still beta stage. I’d rather they didn’t release beta firmware as “the” firmware release…just my two cents.


#13

I don’t see how them putting together a releasable firmware would have any impact on Flex’s manufacturing and shipping rate.

The hardware and the software are two separate components, and, presumably, the hardware is in its final form. So, any work done on the firmware (or any software, for that matter) should have -zero- impact on the delivery rate.

I do believe, based on Glowforge’s own statements and updates, that the firmware is relatively stable and has had few updates. The bulk of the “beta” software work is on the GUI that resides in the cloud, which they haven’t promised to release as open source.

And, they can always release newer versions of the firmware as they become available. Nobody says we are “stuck” with the first version they release. At least, I hope we’re not…


#14

Wasn’t the heat sensor trigger debacle all firmware updates? Betas can and should be pretty stable. That’s why it’s no longer alpha.

But as I said, only my take on it. :grin:


#15

I believe so. It also may have been a combination of cloud and firmware updates.

If they had already released the initial version of the firmware, and then released the revised version after they fixed it, wouldn’t that have been great to be able to look at a diff between the versions? It would be informative to see what they changed.


#16

I think I said it wrong. Getting everyone their machines and having them be as close to advertised as possible in their operation. That does take software work.

The only reason I could think of to need the firmware right this instant is to start the open source work or whatever in preparation for Glowforge vanishing pretty quickly. They’ve got enough funds to be around for a good while.


#17

I don’t think they are going to vanish anytime soon. There are many other reasons.

There are people who purchased this product that are not unsophisticated neophytes. Many of us are avid hardware hackers who bought this platform based on the promise of openness.

While it certainly could be reverse engineered, it shouldn’t have to be. They promised otherwise.

From the link I posted earlier:
@dan “Glowforge firmware is user-flashable, so you’ve got both an escape hatch (if something happens to us) and a platform to experiment with. If you buy it, it’s yours – you should be able to do what you want with it.”
@dan “PS: no pentalobe screws either.”

One could easily say, “Well, they will release it when they are damn well ready. And you should not worry that they won’t do what they said they will do.”

Well…


#18

I think this is an instance where you, as one of the folks smart enough to do something with the firmware, prioritize this higher than I do as one that cannot. I also don’t have a machine on the way yet and am enough of a neophyte that the more magic that the software can do, the better off I’ll be.


#19

I’m not chomping at the bit… I do believe that eventually they’ll release the firmware.

In the meantime, I’ll just be happy when I receive my GF (Can’t promise I won’t be looking under the hood :sushing_face: ).


#20

I’m very optimistic it wouldn’t take very long. http://lasergrbl.com/en/

  • Load GCode with job preview
  • Image engraving with grayscale conversion, dithering and vectorization!
  • User defined buttons, power to you!
  • Grbl Configuration Import/Export
  • Configuration, Alarm and Error codes decoding for Grbl v1.1 (with description tooltip)
  • Homing button, Feed Hold button, Resume button and Grbl Reset button
  • Job time preview and realtime projection
  • Jogging (for any Grbl version)
  • Power and speed overrides (for Grbl > v1.1) with easy-to-use interface