Reminds me of the work Jonathan Oxer presented at LCA 2019 about the journey of reverse engineering and building a similar (and more capable) breakout board for wheelchairs. https://youtu.be/-9Rjh8qJk68
No, because path-style bucket names weren't originally required to conform to dns naming limitations. I don't know how they're going to migrate those older non-conforming buckets to the host-style form.
That's great to hear that you're forcing yourself to keep communication in the open, when at all possible. That's one of the best ways to keep a community healthy.
In my experience with a particular open source project, more than half of new contributors started by communicating privately with myself or some other leader in the project. This is only bad if the communication never moves out of private conversation. I've found it normally takes a few nudges to get people to build their confidence and participate publicly.
Interestingly, it's not only new contributors who suffer from this. I've been told by some of the most prolific contributors to our project that they are still intimidated to speak out publicly. Many times these feelings come from deep-seated cultural norms that don't really fit with traditional Western/American ways of communicating. And that's ok! We all learn together how to best communicate with each other. And we get a healthier community and better code out of it.
I'd encourage you to do it anyway. We're on the same journey at my company. Some of our product is based on a fairly large and active open source project. Others are much more limited and simply at the "here's the code, have fun" stage.
There's different levels of "open source" (everything from one-way code dumps to full-on maintained-as-a-whole-distributed-global-team). In my experience, it's easier to start with a simple "here's the code, bug reports welcome". This starting point is generally an easier sell to management who's worried about project management taking too much time away from other work.
Like all things, practice, start small, and grow from there. Get's easier as you go. But yeah--licenses/legal, written policies, governance, marketing, time prioritization, and more all take a lot of time to figure out.
NB: My own background in open source biases me to thinking open source is "easy". It's not; it takes a lot of work. The good news is that there's a lot of tools and help available for anyone wanting to start.
https://www.superhouse.tv/product/wheelchair-control-breakou... is the result