I've returned to full-time development after 15 years in SA/devops work. I love it and have learned new and new-to-me languages (python and go). Some things came right back and some things still take a little time. Being good at programming is independent of career, it has more to do with drive and desire and motivation.

Your career has more to do with where you want to take it and your flexibility to adjust to the situations that let you go there as much as anything else. There are plenty of shops that wear out their devs and push them in ways that only the young-uns can handle for long periods of time. (maybe that should be people-with-no-life rather than young-uns?) And there are plenty of places that you and I can contribute at high levels and be productive. It seems like you're in the latter as they gave you an alternative and a chance to prove yourself.

This is an internal support decision. As a customer of RCB, do you care if your private cloud is built on the Fedora packages or the Ubuntu packages? You don't manage it at that level, nor at the OS level, so what does it matter? As long as it meets the branding and operational requirements (ie, supports the proper APIs, etc) you have an OpenStack cloud and they don't have an exponentially growing support matrix.

Back in the day we did a first-come-first-served for the full.names, when there was a conflict the user had a choice of (reasonable) options like adding middle initial or something better than a number. In a mass conversion you generally don't have the time ordering to give preference, and with 1.6% you've got a few names to resolve. But you can still generate an email to those users and let them qualify their names more fully and then resolve the conflicts in those answers.

Point is, getting the users involved as much as practical up front reduces support pain later...

I wonder if we get so focused on the technology side of our world that we forget that this work (programming, architecting systens, etc) has a significant creative side and as such the problems that often plague other creative groups. The anguish and troubles of writers, painters, etc are well documented and seemingly (to me anyway) an accepted part of embracing their work. I know that in my own case letting on that I am anything less than 'normal' has been a scary proposition because of the threat of not only being seen as less than capable but also a direct threat to my livelyhood. After all, software people are nearly interchangeable, right?

And Clay's advice near the end (you did read that far, right?) is dead on. We're a group who likes to fix things. We are not trained to fix this. The best we can do is aim someone we are concerned about in the right direction.

I've driven the Futura-based Batmobile, trust me, all the go-fast-drive-hard stuff in the TV series was eventually done with fiberglass replicars. Plus it's sad to see it painted now. Barris originally flocked the car with 'bat-fuzz'. A pain in the a$$ to clean, err, vacuum.

I'm not going to defend the website organization, however you can click on Software at the top, then Getting Started in the left nav bar and you'll have most of the options for tire kicking and downloading and installation guides on one page.

There is no 'one place' to go and get everything, except maybe github.com/openstack and that's only for the brave who are familiar with 'python setup.py install'. If you build Apache and Linux kernels from source this is for you. Otherwise your best bet to play with it is to run devstack (don't do this if you are afraid of screen) or use either Ubuntu's or Fedora's packages. Both of these work in a VM with >2Gb RAM if you can live with qemu providing the virt layer.

Actually there is, they're called Project Technical Leads (PTLs) and some of them do defend their projects from brokenness even when the corporate submitter is really insistent.

The bigger issue is the lack of the overall technical guidance^H^H^H^H^H^Henforcement (I'm not going to use the A-word) for the projects. I don't count the TC here as it's too big and not meant for the in-the-weeds decisions anyway.