There are non-BL folk who are already trying to help improve Studio by submitting patches (“pull requests”) to their GitHub project (myself included now). There’s some good stuff in there, and some of it does get accepted into the code base. There’s usually a list of contributors on the release postings. I might wish for better quality control or whatnot, but whatever, they do accept reasonable contributions… eventually, maybe.
It’s a huge project with a lot of users and ofc any time there’s a problem that’s more support for BL. So I totally get why they need to be cautious about what they change, more so than any independent project, and I appreciate it takes time to review code changes or test new things. I encourage careful code scrutiny and high standards, which aren’t “chap” (in time and effort).
Unfortunately, in this case that doesn’t always result in better (more stable, with fixes and features users actually ask for) software. Worse yet, they’re locking it down more and more to suit their needs and making it harder to work with *. Clearly the open-source requirement is a necessary evil at this point, and I’m honestly not sure they even like pull requests or if it’s just more work for them. Most of their internal development happens behind closed doors, and then synced to the public version in large dumps before a release. That means whatever other outside devs are working with is possibly already outdated on their end (which would also make it harder to integrate).
My biggest frustration so far is getting any feedback over at GitHub, especially on patches. From anyone at all, not just BL folks. Not to say none, but close. (I do realize there are language differences, people are busy, and patience is required.) I mean fixing an obvious exception doesn’t require much communication, but introducing a new feature or change definitely should. Maybe that exchange could be encouraged somehow… I’ve been trying to do some of that myself also, like I’m used to with other OS projects, commenting on other PRs or Issues. Developing anything new inside your own black box has limitations, and often that’s how users end up with “odd” or half-baked features.
Then there’s Orca… which personally I can’t really use because no H2C support. They have a stalled patch submission there to add support, but it’s large and heavy, and seems a programmer with an actual H2C could help (the original patch author doesn’t have one, which is partially why it stalled, understandably, from what I can tell). Maybe my efforts are better directed over there, then. OTOH I’d really like to keep using the “official” software I basically helped pay for when I bought the printer and where I don’t have to switch between multiple (resource heavy) apps to use… among other reasons.
It’s a frustrating situation. I’m open to suggestions. I’m not looking for a job or any material compensation. I just want a good tool to use (like view camera control… how has everyone put up with this for so long?). I can apply my own patches (or any others I like) to my own copy after BL makes releases and use my own version, so there’s that. If others could benefit from that somehow, it would be more motivation, and getting pulled into the main code base saves me time in the future, so that’s worth some extra effort to me. I’ve knocked around the idea of publishing my own version, something with quicker fixes and some feature adoptions, but I don’t want to end up with yet another hard-to-sync fork (or managing it alone, for that matter).
Cheers,
-Max
(There’s a link to my GH page in my profile here, if anyone wants to check my “OS credentials.” Also, if there are any other devs here, Orca or BS, I’d love a DM and frank chat.)
*
Like encrypting the Studio log files now. I can’t read the log files from the official releases on my own computer and we have no idea what we’re sending BL when posting logs for them to debug (GDPR anyone? And yes, like already with the printer logs, though at least those aren’t posted in public). Or that I can’t debug the software (“attach” a debugging tool) when their network plugin is loaded, because apparently that’s part of their “security by obscurity” strategy. These tools are the best way to find exceptions and crashes… not sure how any real developer can work effectively w/out them. Not to mention the obscurity of the whole network plugin is already quite disturbing (I’m the type who turns off all cloud features and locks down the printer at the router).