Well, that was fast! Last week, we wrote about a video by [Norbert Heinz] where he called out the Ortur laser engravers for apparently using the GPL-licensed grbl firmware without providing the source code and their modifications to it, as required by the license. Because open source and grbl are dear to our hearts and CNC machines, we wrote again about Norbert’s efforts over the weekend, speculating that it might just be unfamiliarity with the open source license requirements on Ortur’s part.
Because of [Norbert]’s persistance and publicity around the issue, the support ticket finally reached the right person within Ortur, and within two or three days [Gil Araújo], Support Admin at Ortur, managed to convince the company that going fully open source was the right thing to do. What remains is the question of how to do it, operationally.
So [Gil] asked [Norbert] to ask Hackaday: what do you want from Ortur on this, and how should they proceed? Via e-mail, he asked in particular for best practices on setting up the repository and making the code actually useful to non-programmer types. He said that he looked around at the other laser engraver companies, and didn’t find any good examples of others doing the Right Thing™, so he asked [Norbert] to ask us. And now we’re asking you!
Have you got any good examples of companies using open-source firmware, modifying it, and making it available for their users? Is a simple Github repo with a README enough, or should he spend some time on making it user-friendly for the non-coders out there? Or start with the former and work toward the latter as a goal? I’m sure [Gil] will be reading the comments, so be constructive! You’ll be helping a laser engraver company take its first steps into actually engaging with the open source community.
We said it before, and we’ll say it again. Good job [Norbert] for taking Ortur to task here, but also by doing so in a way that leaves them the option of turning around and doing the right thing. This also highlights that companies aren’t monolithic beasts – sometimes it takes getting your cause heard by just the right person within a company to change the response from a “this is a business secret” to “how should we set up our Github?” And kudos for [Gil] and Ortur for listening to their users!
I mean, in the comments it seems that they don’t have experience making a repository. Makes me wonder what their version control and deployment looks like.
To be honest, this should be pretty simple, unless they’ve really kludged the codebase up. Fork GRBL, commit codebase, diff. Trim the inevitable fat that comes with unmanaged codebases. Maybe work on gitignore. Make repo public. That would get them where they need to be, and then they could integrate deployment tools as desired to make their lives easier.
TBH, this kerfuffle could be the best thing to ever happen to their developers.
According to my contact person at Ortur they are working with a Chinese version of something like github and as usual: The devil is in the details. “Should be pretty simple” is the trap I find myself in whenever I start a new code related project ;-)
Yeah, that’s my current proposal engineer vocabulary coming out, implementation teams hate it when the words “just do this” or “should be as simple as” come out of our mouths.
Still, like Elliot has mentioned in previous coverage of this saga (thanks for kicking it off, btw!), GRBL is pretty robust and they shouldn’t (there’s that word again) have had to muck around with it much at all to get it working. The (hopefully) bigger struggle will be adapting their engineering and management workflows to git, which will have payoffs in the long run.
Norbert mentioned that they ported GRBL to a different chip, added a heat/IR sensor to tell when things are burning, etc. So there definitely was some real development work done here.
maybe… The bootup banner on one of the machines says grblHAL, it uses grbl but runs on many different chips and has many more features, https://github.com/grblHAL
If it is true that they use grblHAL and ported it to different chip, then they should merge their changes back into the code base or fork it and merge. Though the whole point of grblHAL is eliminate all those random Grbl ports out there. grblHAL is pretty easy to port as the HAL part of the name implies – it already runs on a very wide range of MCUs .
Ahhhhh the poison allure of the “five-minute job”
Yeah. Is this not part of software development education?
At least as of ~7 years ago at a decent 4 year univ studying computer science I can say, no it is not unfortunately. I would have greatly benefited from having that in class instead of just cobbling together some versioning knowledge for myself between projects.
Your supposed to learn how to learn the tools in school
Not just learn the tools.
There’s other source control systems. I worked 10 years using a different one and found git very strange when I first used it.
i think, your most right! But Put IT on git is the First step , link a forum for the user is also one, (let the users help them self beginnges learn from enthusiasts) and so a company can learn from users and know there wishes , so they can evolve rhe company also(yes with profit in mind) i think this
Is the beginning
Awesome – that’s some good news for a Monday!
I almost bought one of these a few weeks ago, but if they go open source I’d def buy in. If they are going to os it , they might as well also allow some open builds, like 3d printed parts and stuff to make your own
The code is for coders, so git repo seems enough for anyone interested in and capable of using the code. GH allows publishing release binaries, so non-coders can grab them easily and have a well known place to look for updates.
However, this is very basic approach which brings little benefit. Much better solution is to
submit modifications upstream for integration. If your changes are mutually exclusive with the upstream code, you should make the project configurable.
If you do, you may try working with upstream and provide a website with configurable-downloadable builds like https://nodemcu-build.com/
I agree that the code is for coders and should be packed for developers so that they can continue providing firmware upgrades as they have in the past in zip files.
As for where or how they should release their code, why not start with them providing a text diff of all the changes from a release(will also include which files were changed so one text file does the trick) and then provide the source as a zip package including a README.TXT with build instructions.
Keep it simple, make it easy for Ortur to provide basic documentation of their changes and easy for them to post the source. No need for them to setup a github.com or gitlab.com repo just yet because maybe the Chinese government would then need to be involved, etc. KISS and it’s likely to happen.
Or instead of offering a patch file, going the 2022 route of using git and hosting the repo somewhere publicly. So much more convenient than a diff file for 99% of devs.
Dude, the path file is to show what was changed on what lines in what files… If you read my statement it stated a patch file AND the source in a zip file so they could jump quickly getting the source out and without disrupting their business. But ya, they could redesign their development environment and make it all nice and handy and while their at it create a support forum and hire a few employees to support it while doing it all yesterday so nobody else complains.
Or they could just put it all in git, instead of trying to figure out what’s a real diff and what’s not and generate a diff file.
Clearly these people don’t know how to git, or diff, asking them to learn that AND git, AND everything else on-top.
Just put it on git, and get more complicated from there after all the code is available.
Others will have an overly specific opinion on what more you could do (like make a diff file and distribute that etc) but we can’t really know how big an effort that is till we see the state of the code as is.
If we’re talking in generalities coders don’t want zip files, they want it on github or maybe a repo hosted by Ortur or something like that.
Coders want to code.
Next thing is to collaborate with other coders.
And for better collaboration there is https://sfconservancy.org/GiveUpGitHub/
> Coders want to code.
Sure, but that doesn’t really have any relevance to the subject at hand.
The “they” I was referring to was the Ortur devs who package up zip files of their firmware to be flashed onto their STM32 based boards. And not all coders want to go anywhere near Microsoft’s github if you want to generalize.
My comment was to show a path so Ortur could meet GPL requirements with little business disruption. But if you want your cake and eat it too then by all means follow the many posts which asked that they learn git, create or use a public repository and provide the full build environment and documentation.
> And not all coders want to go anywhere near Microsoft’s github if you want to generalize.
As I mentioned there’s tons of alternatives to github.
Ortur already uses git, there’s no reason for them to take a step back to the 2000’s and distribute source with zip files.
yes, now we know Ortur has a git repo even through they don’t use it but seem willing to start using it which is great.
This info was not gleaned until recently and after many had already posted.
The first sentence of your second paragraph sounds like more work for the distributor than including a static license file with reference to the distributor’s git repo and a mention of GRBL. The rest of it reads exactly like cloning a git repo, just with more effort for the distributor (and less secure, to boot).
The only way those are simpler is if they aren’t using git or another easily hostable version control system. And if they don’t, they only save effort until someone makes a mistake (or just stops manually working on GPL compliance) in either manual transcription to the diff file or some kludged together homebrew script stops working.
None of this feels like KISS to me. Relying on proven version control does.
Even if they don’t upstream, if they at least do the minimum and release their source it allows machine owners to see the changes, and that is enough to get upstream modified and running on the machine. it just takes one person doing this and submitting a pull request for support to get added to the upstream. They don’t even really need to make a repo, we just need a tarball of source.
That is where the real value to consumers is with these open source machines, and it’s the reason I factor in whether companies meet their GPL obligations when purchasing a machine like this.
The fact is these branches made by small hardware vendors are usually pretty low quality from both a code and feature standpoint, and they are rarely maintained. This isn’t about them “sharing their innovations” so much as keeping end users from being trapped with low quality firmware.
An open–source creators view/perspective:
If it’s gpl, that means that there needs to be a GitHub, gitlab, or some other hosting site that’s easily accessible for users, to view, fork, and modify Orturs version of the grbl firmware; while this doesn’t require them to add notation to the code for developers, such a move would make you popular with open-source fans, and could even result in great improvements to your end product with lesser costs on the companies engineers. I’d also recommend instructions for users to change their firmware if they so choose (this may be a requirement of the license, I’m uncertain).
If you wanted to go above and beyond:
Open source as much of the products design as you can, from printable files for any parts that can be printed or cnc‘d
To open source designs for controller boards for users to order or make replacements based on.
This will both make Ortur look good, and help them as a company build trust with communities who’s work they use, and whom could help improve company products.
The GPL doesn’t specify that you have to use git or anything like it.
I’m not sure how Ortur is distributing the firmware, but if it comes embedded in the device, then section 6b of the GPLv3 would apply, meaning they can provide source code in a physical medium upon written request, and they can even charge a nominal fee to cover the cost of the media and delivery.
However, if they’re distributing the firmware via a website, they’re obligated per 6d to offer the source code for download as well.
The great thing about the GPL is that anyone can establish that repo if the vendor prefers not to — if we just have a tarball the community can take it from there.
Hello Everyone
And thank you for the feedback so far
I will be taking a close eye
A few notes and corrections if i may
ortur.net is actually a retailer front, not the corporate website (Unsure if Elliot Williams could do a little correction)
Ortur.tech is where we currently host most of our data.
As per the repository. As Norbert Explained, currently the team at HQ uses Gitee (as i understand it a alternative of github for the chinese market)
Now i must preface I am not a coder, far from it, so i would hope you all allow me the less technical language.
The most complex part on the migration is in part, lack of prework on organizing the original repository
But also the fact more recent firmware is based mostly on modules of code on top and on the side of GRBLHAL
This modularity is – aparently – simpler to work on a local envorioment, but makes the respository a bit complext to build
Firstly the modules will have to be imported as Submodule (github version), then added to the main repository as “links”
Rough estimation theres roughly 130 modules to import, comment clean and document. So will be a bit of a work load, but the team is happy to do it.
We might start uploading older versions of firmware, for 2019/2020 machines which are not too complex nor are in current development, and then grow from there – Hopefully as well – using these initials commits of code to get some feedback on what we doing right and what we doing less wrong.
As per the Where:
Ortur has a GitHub Home
https://github.com/Ortur-Intelligent-Technologies
Also created a Discussion – which if i did it right should be “public” facing and would be open to any sugestions
https://github.com/orgs/Ortur-Intelligent-Technologies/discussions/2
gilaraujo@ortur.cn will also be closely watched while we prepare a email dedicated to firmware and repo issues.
Any questions or sugestions, please let us know. And also feel free to ask any questions you seem are relevant, i will try to answer as best as i can
Gil Araújo
Ortur
Hi Gil and just to let you know, THIS is the kind of stuff which drives people to Ortur. Thank you for working to be part of the community and working to make laser cutting and engraving something almost anyone can do. Ortur has lead the way with the LM1 and keep on going.
I don’t even have one of your devices, and everyone makes mistakes. But this kind of community engagement says volumes about the way your company operates. Well done, and good luck moving forward!
some other chinese hardware companies are already on Github/gitlab like TTGO, they deploy the source code in a repo and in their case another repos for code examples and diagrams, they internally have another software for version control, but any developer can grab the code, customize or even help on development. Github and Gitlab have so many fancy feaurres (like Ci for auto-generate compiled files, coloring tags ….) but initially just provide the source code is fine for any developer. In a future even your hardware could grab the latest version of firmware directly from Github/gitlab (or even your own server), but again , start with basics.
Well done Gil and Ortur, I’m proud of you guys for doing what is right.
Those links now show 404 page not found
They moved it all to a new page:
https://github.com/orgs/Ortur-Tech/repositories
The obvious parallel would be Prusa’s fork of Marlin in Github: https://github.com/prusa3d/Prusa-Firmware . The README.md has been customized to make it obvious it’s a heavily modified fork, gives instructions for setting up a build and dev environment, and how to build and flash to a printer.
Same thing with their Prusaslicer repo.
Another similar example is Framework’s repo for their laptop’s EC firmware: https://github.com/FrameworkComputer/EmbeddedController
Although not as well documented, there’s also Google’s upstreaming of their contributions to Coreboot for every ChromeOS product on the market.
What do I want to see? Source code, toolchains, schematics, board layouts, BOM, mechanical CAD drawings, and… like, all of it. If the source code can’t be compiled, it’s clearly not what’s running in their machine, so proving it with a working toolchain would be a minimum. The rest of it is jist smart to be complete and offload supporting their product to the community. Any product that gets (through their own planning or otherwise) openrd up for community hacking gets bought like gangbusters.
Err… whilst open sourcing the hardware would be nice, realistically, companies which give away all their IP are pretty hard to get investment. You’re basically trying to convince an investor that your name is worth something, and that people will keep giving *you* money instead of getting an identical ripoff cheaper off ali.
You couldn’t realistically undercut Ortur. Their machines are about as inexpensive as you can get and still have a viable product.
Their support is surprisingly responsive, as well.
Seriously, the price of Ortur engravers is right at that “I almost don’t trust it because it’s too cheap” and other engravers at that price point ARE garbage.
Their support is what makes them worthwhile, and this can only increase their brand loyalty.
well said and I agree and I have had interactions with them. Not to fix a machine I had but to fix machines others had because of failed firmware updates.
Fair call, though unfortunately there’s always someone who’ll undercut and NOT have a viable product. And besides, if you don’t have to pay devs and engineers because you’re stealing someone else’s work, there’s immediate savings.
The CNC I bought came with a cracked copy of Corel draw and a virus… thankfully the GRBL on the board was fine, and there’s CNC.js
You couldn’t… and I couldn’t.. but they don’t just have you and I to worry about. They have every other manufacturer in the game looking as well.
Just pulling even in one area like hardware design could put some other company ahead thats already better in other ways like having a bribe in for shipping, or a corrupt import tax assessor in some country.
Prusa does that. Anyone can make a 3D printer 100% identical to a Prusa other than putting the name Prusa on it. But nobody does make one quite 100% identical. Prusa still makes money selling 3D printers.
Unless they are using other open source projects in their product then they have no obligation to open source anything other than the version of GRBL that they use. It is very hard for a company to make money if everything is open source. If the control boards are open source then people may just buy cheaper versions from other vendors, other vendors may also start selling a slightly cheaper but otherwise identical product, and people tend to go for what’s cheaper.
Even Arduino has found this and this is why some of their newer boards are not open source, like the portenta H7, they don’t want people copying it and selling it cheaper.
You may argue that more people will buy it due to the support they can get, if the support is all community based then it doesn’t matter if you have an original or a clone, you can still get the same support. Also it would be a major shift in business model, instead of selling a product as is, just to be used, now you are selling a product that is meant to be modified and if it’s open source people will expect a lot of engagement from the manufacturer. It is no longer their product, it is open source, it also means that someone else could come along and create basically a clone but with a few improvements and if it is sufficiently better than the original and still cheap enough then people will buy it instead.
In most business you are only competing with other companies, if you open source your whole product then you are competing with other companies, with companies that just clone open source products and you are also competing with the consumers and any consumer who decides they can start a business and make and sell the product on their own.
In short, open source is good but it pretty much eliminates competition between companies and is therefore unsustainable for the business. Also if companies are sneaky about using FOSS in their products and do it in a way that no one can find out they are using FOSS, then they don’t need to publish their changes, it also means they can make major changes and not advance the open source project, this also means that a closed produ t that relies heavily on open source can access and incorporate all the advancements from their competitors into their own product, without sharing their own advancements, so they would always have an advantage. It isnt moral but as we have seen with Ortur it is possible to hide that you are using FOSS, and Ortur wasn’t even trying to hide it.
A perfectly condensed pile of BS.
If your product is targeted at the maker community and it is not open source, it had better be a LOT cheaper for equivalent functionality. I wouldn’t pay full price for a car that has its hood welded shut.
Companies get away with these arguments for consumer crap marketed to the general public. They also get away with it for high end B2B models where most of what you are paying for is ongoing support from the factory.
For these race to the bottom hardware vendors going after a price point on Amazon, selling to a community of people that generally buys the product for the express purpose of hacking on it, trying to go the proprietary route is a no-go. You need to document your products. Period.
@conor stewart, fundamentally untrue. Design files need not be published but source code must per the GPL.
Yeah, abzman2000, it would be nice to see them publish “… like, all of it.” I hope, however, that they follow the github-code-for-the-coders advice right away — rather than hold it all back while they figure out what new business model could possibly support opening up everything else.
I hate it when people make excuses for projects not following a license. They did the same thing with Creality who full on knew what they were doing with Marlin and they made millions. We just didn’t see good enough examples is not an excuse.
They should be providing source changes. Up to date board layouts. Whatever steps users or programmers would need to compile a working firmware. They can do what Prusa does and only provide some stuff to users and have an escalations process. As long as there is a way to get the info when users need to make changes.
Thanks Elliot for the blog entry! Just want to drop a note that the official Ortur page is https://ortur.tech/ not ortur.net as linked in the article. The later is just a retailer.
Thanks! Fixed.
Boy, that’s not confusing at all… And ortur.com seems to be parked. Yuck.
As far as the GPL is concerned, a link to a zipfile that contains the working code satisfies the requirements. Anything beyond that is gold plating with two distinctly negative consequences:
First, it’s an additional, unnecessary burden on the company. If we want companies to obey the GPL, it’s in everyone’s best interest to make doing so as easy as possible. We want senior management and corporate legal to say, “so the cost of ‘GPL compliance’ is something the programmers can do in five minutes. Why are you wasting my time with this?”
Second, gold plating takes time. We don’t want “jam yesterday and jam tomorrow, but never jam today.” We don’t want ‘a commitment to being good citizens of the FOSS community’ that starts with half a dozen focus groups and wishlists for things that may never be possible to implement, all of which add up to excuses to push off publishing the code to ‘someday that isn’t today’. We want code, and we want it promptly.
As a sanity check, a large fraction of FOSS projects are high-unreadable code with no documentation at all. Of the documentation that does exist, a large raction is incomplete and/or out of date. If we demanded well-written, well-documented projects, the FOSS canon would consist of Knuth’s TeX compiler and a few dozen people complaining about having to learn literate programming.
We can respect Ortur for wanting to provide a good FOSS experience, but let’s not front-load the effort. Start with the simply-met requirement to publish the code at all, follow that with making it possible to communicate with people using the code, then start iterating. The decision criterion is ‘what we can deliver today that’s better than yesterday’.
Uploading a zip of one version of source code is easily. Consistently doing so over multiple revisions is surprisingly difficult. I maintain that forking GRBL is not very difficult.
Well said.
thank you, someone who understands a process change is lots to ask and there are steps to the solution which can get everyone working together quicker and on good terms.
Yes, zip file fulfills requirements of GPL. However, I don’t see a bright future ahead of a company that can’t leverage open source model to a greater extent (and don’t manage their code properly with git or some other VCS). Investing some more time/money in a better community oriented source management will pay off with bug fixes and new features developed by users. If senior management and corporate legal don’t get it, I, as an engineer in Ortur, would be looking for a new job.
I suggest that they make it open and then sell services around the product like tech support and hardware upgrades. That way they still make money, even if knockoff products are made.
“Worse is better”. Get something pushed to github, whatever is easiest to do first. Then watch the github issues and pull requests, and hopefully folks will have some recommendations for how to better structure the code, how to extract patches which could be upstreamed, etc. I think the most important thing is that (a) the code “as it is used internally” exist (that is, don’t wait to “clean it up”, that just adds confusion and delay; if it was good enough to burn onto the machines at the factory it’s good enough for an initial upload), and next priority after that (way before “clean up the code”, “upstream it”, etc) is “write good instructions for how to build a functionally-identical copy of the firmware from the bits that were pushed to github and burn it to the device”. Don’t worry if step (b) currently requires proprietary compilers or expensive site licenses of magic dust or whatever. First step is to document what is currently being done, in a reproducible way. That gives the broader community the tools to take it from there.
That’s not to diminish the importance of free toolchains, nice commit histories, upstreaming contributions, etc; just that all those latter things can be built on top of the foundation of “what we’re currently doing right now and burning to the machines”, and it is easy to budget an indefinite timeline for eventually getting to the former while never actually just getting the latter done.
Another way of putting this is: the best way to get good and useful advice is to post as much info on where you’re currently at, and you get that done by doing the quick and dirty “upload a zipball of our current sources” or whatever and satisfy your GPL obligations at the same time. Once we see what you’ve got we can see where better commit history would be useful, or a noncommercial tool chain, or whatever.
The biggest thing off the top of my head, let a couple security guys comb through the repo before you make it public. It’s far too easy to include bash history, or other security tokens in a dot-file, that are not intended to be public.
Beyond that, it’s great to have some instructions on how to contribute, and worth thinking about whether you need copyright attribution for outside commits. And finally, a reasonable path with instructions on how to compile and run your own firmware, and what that does to your warranty.
Ideally, this step will result in bug fixes and even new features coming in from the community. Hoping for the best!
“The biggest thing off the top of my head, let a couple security guys comb through the repo before you make it public. It’s far too easy to include bash history, or other security tokens in a dot-file, that are not intended to be public.”
This is actually a great point. i will pass along. Didnt consider this
Thank you!
I have no suggestions, but as an Ortur user of many years I applaud this move. Thank you.
Congratulations, Ortur!
A small nit: had it to be Github, of all things?
BIGTREETECH are a decent example. They host both source code and binary release repositories on GitHub. This caters for both the tinkerers and those who just want to install the latest firmware release without having to build from source (i.e. the majority of users).
Switching to Build and Deployment pipelines in Azure Devops is one of the best things to happen at our place. Complete traceability, easily deploy to UAT and then Prod, uniform build environment for all developers. Previously we had people modifying code and config directly in Prod which would never make it’s way back to source control so someone pushing out changes would wipe something, or we would discover that the version that was out in the company was completely different to the latest commit and never checked back in by someone who had left 2 years ago, or they had spent ages making changes and checked them in but it got dropped and never pushed out. With the pipelines we can more easily see which version was actually pushed to prod.
I love it so much now that I’ve rolled my own Gitea and Drone server at home for personal projects.
No mention of Naomi ‘SexyCyborg’ Wu? If she was able to help Creality get inline with GPL/opensource requirements, I would imagine she could at least offer some input.
Nice as it may seem, but based on the GPL is Ortur under any real obligation to publish schematics, board layouts, and b.o.m? (These seem far outside the range of the license’s intent (firmware, software).
It’s understandable that Ortur needs to document how they’ve used the grbl stuff, modified it for their system, bugs and fixes they’ve uncovered, etc., but how does one draw a line between that, and other code that wasn’t forked from the original. Say some magic code library, but all you’d see in the grbl fork are random calls to the library, but no documentation on what’s behind the curtain or how’s it done. What’s the obligation there?
How do you delineate the boundaries?
This is one of the things i wasnt aware in the fullest extent – but became much more aware in the last days.
The idea that ortur machines use a version of Grbl (Or GrblHal – which is an extention of Gbl on its own) with just PIN I/o changes is a bit simplistic.
In fact there are a great ammount of modules, features and plugins added on top, to combine into a binary that creates what ortur machines do.
Now in an ideal world, and this is a thought i had recently as well, what this repository might also allow is users to run GRBLHAL to is simplest way, removing all bells and whistles, and devote the full resources of the MCU to ONE job only. Streaming Gcode. Recompile the firmware and run it.
However, as many might be aware, the security features and all aditional features added rely on a lot of other modules. Some of these features are mandatory for certifications and alikes, others are… “nice to have” and others we found over time are more of a pain than a feature. Allowing more advanced users to have a firmware bespoke to their needs – which they then could share with others with the same needs – could be of huge benefit for everyone.
The best way to make a repository thats not a ants nest, is something i do not have the technical skills to understad so i will rely on the team to figure that out
Some other users also asked about how ORTURwould provide warranty and support.
We have nothing set in stone regarding support, however warranty will not be affected on firmwre basis, unless a user compleatly bricks a board beyond software repair.
On the support side, we will have to draw a line somewhere, as our support team is not
a) big enough
b) skilled enough
to handle a theorically unlimited variations of firmware users could conjure up once open source is available.
I am thinking though, ultimately for diagnostics on the hardware part, users can always rever to standard stock firmware , run diagnostics, and then revert back to their firmware of choice.
Another fact that becoming evident is that devil will be on the details, but with some patience and the community feedback we will find out the boundries corretly.
Regards
with mandatory certifications, safety and where to draw the line on support, something like this might be an option.
https://hackaday.com/2019/12/16/prusa-dares-you-to-break-their-latest-printer/
Good job. Now, can someone get on Flsun’s case for using Repetier Firmware without sharing the source?
Does anyone know anything about the FDA in the USA cracking down on light sources like the one used here? Illegal Chinese light sources are causing all kinds of problems.
1 month later and they’re just using github as a file service for their documentation. Not a single bit of code. They just need to delete the build directory and zip up the source code, which in its simplest form takes about 5 minutes. I’ll believe it when I see it.
Looks like they deleted it entirely now
They moved to a new page and started publishing the sources, even more then just the grbl core:
https://github.com/orgs/Ortur-Tech/repositories
Ah, thanks, I did try looking elsewhere but nothing came up.