Open djpimp2010 opened 1 month ago
sebb3
commented
1 month ago Unfortunately it seems like anycubic have no interest in making this a good OSS project. They have open sourced it by pure obligation because of early promises and lots of complaints. very unfortunate, this could have been so great. Im getting rid of my printer in favor of some other brand. I give up!
WaresWichall
commented
1 month ago @sebb3 is spot on, they're only open sourcing the bits which licensing requires them to.
For example: https://github.com/ANYCUBIC-3D/Kobra3/blob/main/klipper-go/project/adc_temperature.go#L18
GPLv3 obligates anycubic to distribute the source for any parts of their software where it is used, so they've stripped out all proprietary code that doesn't rely on open source licensing.
I'm also getting rid of my printer and abandoning my anycubic python api + home assistant integration
detiber
commented
1 month ago Look, I get the frustration, I too would love if this repo/code was fully documented. I'd also prefer that all of the code was open source, rather than also containing proprietary components.
That said, I think the tone and rhetoric here (not including the original poster) needs to be dialed down a bit (or redirected to corporate feedback/support channels), for reasons that I will explain below.
I don't think the situation is as dire as some folks are making it out to be. For example, taking a quick tour of the source tree, I was able to find some gems like:
There is no doubt that Anycubic as a company shouldn't have done a better job with the handling of the source release.
I'm also not letting them off the hook for continuing to improve the documentation, usability, and comprehensiveness of configuration needed to reproduce the open source components of their firmware.
From my perspective, though, having been involved in building product offerings based on open source projects, this seems more like a case of trying to balance the challenges involved in building, shipping, and supporting product (which brings in revenue and makes the business and the majority of consumers happy) vs all of the work involved to untangle build/config from internal tooling/process/documentation, fully document an open source friendly process/config, and test/validate everything.
Even companies that are well versed in this type of thing, like Red Hat (disclosure, I was a Red Hatter from 2011 - 2018) face challenges with open sourcing code inherited through acquisitions, and the documentation/build tooling related to their various upstream projects varies quite a bit, with some being quite difficult to reproduce outside of their product build pipeline tooling.
Of course, with a little bit of planning and engineering work up front, a lot of the pain, effort, and time involved could be avoided. But that is a trade off between the cost/benefit of slowing down the initial deliverables vs paying down the tech debt accrued later. I know I've fought too many of those battles over the years, only to watch most of them unfold exactly as I predicted, so I'm sympathetic to those that have to clean up the mess.
I obviously don't know what the situation is like for @yangyuanxin, but from my personal experience, this is how I've generally seen it play out:
This type of work generally falls on the shoulders of the folks that care the most, often trying to juggle the work with the various demands placed upon them based on "business priority". Their hands are also generally tied in what they can say publicly, so they often cannot even explain when the inevitable negative complaints start pouring in. Even if they could, it takes precious time away from being able to execute on the thing being complained about, which they generally aren't being allocated enough time to work on anyway, with work like this eating into professional development time/passion projects/personal time. After a while, if all you are getting is stream of non-constructive negative feedback, angry complaints, and taking the blame for the decisions of others, the motivation to continue the work dwindles.
It's actually more counterproductive to load up the GitHub issues with comments like this:
More productive ways to express your frustration with the situation:
Yangyuanxin
commented
1 month ago Dear Jason, Thank you for your advice. I will make sure to pass on your feedback to my company tomorrow. I also hope to see this open-source software thrive in the community, and I believe that things will get better in the near future. Thank you. Best regards!
Bruce.yang ------------------ Original ------------------ From: Jason DeTiberus @.> Date: Wed,Oct 23,2024 0:11 AM To: ANYCUBIC-3D/Kobra3 @.> Cc: Yangyuanxin @.>, Mention @.> Subject: Re: [ANYCUBIC-3D/Kobra3] Walkthrough of steps from git clone tocompilation to upload (Issue #3)
tldr;
Look, I get the frustration, I too would love if this repo/code was fully documented. I'd also prefer that all of the code was open source, rather than also containing proprietary components.
That said, I think the tone and rhetoric here (not including the original poster) needs to be dialed down a bit (or redirected to corporate feedback/support channels), for reasons that I will explain below.
This is going to take a while
I don't think the situation is as dire as some folks are making it out to be. For example, taking a quick tour of the source tree, I was able to find some gems like:
https://github.com/ANYCUBIC-3D/Kobra3/blob/91d9771204b00242668a02586cf317a58a1aa26f/klipper-go/docs/N033%E6%96%99%E7%9B%92%E9%80%9A%E4%BF%A1%E5%8D%8F%E8%AE%AE.md (Translated to English via google translate: https://github-com.translate.goog/ANYCUBIC-3D/Kobra3/blob/91d9771204b00242668a02586cf317a58a1aa26f/klipper-go/docs/N033%E6%96%99%E7%9B%92%E9%80%9A%E4%BF%A1%E5%8D%8F%E8%AE%AE.md?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)
https://github.com/ANYCUBIC-3D/Kobra3/blob/main/klipper-go/project/ace_proto.go
https://github.com/ANYCUBIC-3D/Kobra3/blob/main/klipper-go/project/Webhooks.go
https://github.com/ANYCUBIC-3D/Kobra3/blob/main/klipper-go/project/console.go
There is no doubt that Anycubic as a company shouldn't have done a better job with the handling of the source release.
I'm also not letting them off the hook for continuing to improve the documentation, usability, and comprehensiveness of configuration needed to reproduce the open source components of their firmware.
From my perspective, though, having been involved in building product offerings based on open source projects, this seems more like a case of trying to balance the challenges involved in building, shipping, and supporting product (which brings in revenue and makes the business and the majority of consumers happy) vs all of the work involved to untangle build/config from internal tooling/process/documentation, fully document an open source friendly process/config, and test/validate everything.
Even companies that are well versed in this type of thing, like Red Hat (disclosure, I was a Red Hatter from 2011 - 2018) face challenges with open sourcing code inherited through acquisitions, and the documentation/build tooling related to their various upstream projects varies quite a bit, with some being quite difficult to reproduce outside of their product build pipeline tooling.
Of course, with a little bit of planning and engineering work up front, a lot of the pain, effort, and time involved could be avoided. But that is a trade off between the cost/benefit of slowing down the initial deliverables vs paying down the tech debt accrued later. I know I've fought too many of those battles over the years, only to watch most of them unfold exactly as I predicted, so I'm sympathetic to those that have to clean up the mess.
I obviously don't know what the situation is like for @Yangyuanxin, but from my personal experience, this is how I've generally seen it play out:
This type of work generally falls on the shoulders of the folks that care the most, often trying to juggle the work with the various demands placed upon them based on "business priority". Their hands are also generally tied in what they can say publicly, so they often cannot even explain when the inevitable negative complaints start pouring in. Even if they could, it takes precious time away from being able to execute on the thing being complained about, which they generally aren't being allocated enough time to work on anyway, with work like this eating into professional development time/passion projects/personal time. After a while, if all you are getting is stream of non-constructive negative feedback, angry complaints, and taking the blame for the decisions of others, the motivation to continue the work dwindles.
It's actually more counterproductive to load up the GitHub issues with comments like this:
It's highly unlikely that the folks making the actual business decisions around prioritization/urgency will see them.
They are highly likely to demoralize the folks that want to help and are in the best place to help.
More productive ways to express your frustration with the situation:
Send complaints to the appropriate email addresses listed here: https://store.anycubic.com/pages/contact-us
Huge bonus points if you have bulk buying power or would qualify for their affiliate/reseller programs and can provide a solid case for it being financially beneficial to them
File an issue with support: https://anycubicsupport.zendesk.com/hc/en-001/requests/new/
Post and signal boost similar complaints through their community channels: https://store.anycubic.com/pages/anycubic-community
Use social media, blog, related forums/communities to help generate more visibility around your complaints
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
steus83
commented
2 weeks ago The repository is not complete, you can only compile gklib, the rest of other component (like gkapi) are not present.
I successfully compiled source after some studies, and i can confirm that this code is not the last code, and for example:
So, dear @ANYCUBIC-3D this is not the correct way to manage open source project and releative sources.
Hi anycubic
I'm super grateful you decided to opensource your firmware
Can you please add to the README instruction on how to compile whatever is necessary from this repo, and then how to use whatever is output as a file to use for firmware upgrade?
Sure, I could sit here day, after day, running compile commands on all the folders in this repo, until I figure it out, but you could just explain how to use it.
Thank you.