NASA and Open-Source Software
lwn.net
lwn.net
For awhile, I was working at NASA on an open source project. I had idealized NASA based on movies, and thought it was the kind of place where one could be bold with coming up with novel solutions to hard problems. I was naïve enough to think that if I had good solutions I could ignore the bureaucracy. I was extremely productive and often speaking up and contributing confidently in meetings. I ruffled feathers, and thought it was fine as long as my work was good. Around a year in, a middle manager started to micromanage who I was allowed to communicate with. I recall a point when I asked a superior, who had a cubicle next to mine, and who I had a positive relationship with up to that point, how his weekend was. He didn't respond and later that day the manager called me into the office and reprimanded me literally to the point of tears, for "going outside the chain of command". Eventually, despite being the most productive member of our open source team, in terms of open issues resolved, new features shipped, and tech debt paid off, I got fired for "low performance".
The lesson I took away is that I shouldn't work for bureaucratic organizations like NASA.
PR or Reputation management can force a culture onto people which might be a bit toxic behind the scenes and some people just do not like their authority challenged, so stepping outside of the box even the mere suggestion can be a deadly experience.
Thinking back to Boeing's recent 737Max issues, I wonder how much managerial exchange is there between the two Aerospace organizations.
[1] https://en.wikipedia.org/wiki/Rogers_Commission_Report#Flawe... [2] https://en.wikipedia.org/wiki/Columbia_Accident_Investigatio...
But I think your root mistake is in your measures of "performance". As a programmer you measure bugs fixed, features added, debt removed. Your manager though has different criteria (for himself, since he does none of those things) and some of his criteria bleed onto you.
Things like communication, documentation, co-worker relationships, priorities and focus, and so on. (for all I know you were excellent at all these.)
In my experience the most frustrated employees are where they want to play by one set of rules, but the organisation plays by a different set of rules. Funding the place where your ruleset match the organizational is critical.
I would wither in a place that was all process and little result. But I've also seen people wither at my office because there's a lack of formal process. Right person, right place, right time, is when the magic happens.
I love middle-managers. It’s the one occupation everyone hates, but its sooooo important. They are able to keep focus, and make sure corporate pathologies don’t sink in. Plus, they’re very nice people.
I like chit chatting with the devs two floors up. They’re usually working on different projects, but facing all the same issues. Learning about the other teams around coffee or at lunch is fun.
I love the rumor mill. So and sos team is being split up. The manager that just resigned is starting his own company. We are about win a gigantic contract with the NSA. None of it’s true, of course. But it’s fun!
I like having an accounting department. We have these crazy accounting people who do all their work out loud, so we always know what they’re doing. I once heard then arguing over my paystub, so I walked over and asked if I could help. They were shocked I was real person and not some numbers on paper.
The politics are better when the company has a more formal way of doing things. Good companies have a cursus honorum.
At the end of the day I like big companies for the same reasons I like big cities: lots of people.
I know someone who knows quite a bit about the military-side of this space, and we were discussing a related problem: the US's capability of ramping up war-time production if we get into a hot conflict with Russia or China. The amount of waste, bureaucracy, and cost that goes into all of our military contracts would simply have to change, or we'd be screwed.
This friend of mine thinks we'd figure it out, but I'm not so sure.
This strategy itself created problems for long-term through-life support of a suddenly incoherent vehicle fleet but in turn increased motivation to develop standardised vehicle architectures [2] to allow faster modular upgrades.
This approach isn't going to suddenly deliver a new type fighter aircraft in the timescales of a hot war with China, but it does demonstrate that at least one NATO acquisition system could be speeded up a bit. A current example that is being worked at the moment is how to ramp up supplies of artillery and missiles for supply to Ukraine.
[Edit] Things more generally have slowed down again, e.g. as evidenced by the UK's (failed and cancelled) Warrior Capability Sustainment Programme, a disastrous attempt to upgrade the British Army's primary armoured infantry fighting vehicle.
[0] https://www.gov.uk/guidance/standing-commitments
[1] https://www.gov.uk/guidance/uk-forces-operations-in-afghanis...
[2] https://en.wikipedia.org/wiki/Generic_Vehicle_Architecture
[3] https://en.wikipedia.org/wiki/Warrior_tracked_armoured_vehic...
This by itself would have been enough for me to walk out. Toxic.
By far the biggest problem is that we don't get any time at all to devote to maintenance. The second the NASA project I wrote the software for stopped paying for my time, the project became a personal labor of love/hate. If I ever leave NASA, I'll lose my ability to merge PRs and presumably the project will be completely abandoned despite receiving fairly regular contributions from the community. I have no particular use for the software myself, so I sporadically review and merge PRs in my spare time entirely out of a dubiously founded sense of obligation to the people who bother to submit them.
I'm the sole maintainer of another open source project at NASA. I'm super stoked about it, and because of that the project will live, not because of anything NASA does. It doesn't live at github.com/nasa, which is a good thing: if I leave, I get to take it with me. Every place I've ever worked (including NASA) doesn't care about open software one way or another: if you want to release stuff and maintain it publically, you can. They don't care.
For those too young to remember, before ImageMagick came along, xv was pretty much the image viewer to have under Linux. It's still around, $35 and shareware: https://en.m.wikipedia.org/wiki/Xv_(software)
The territorial limitations effectively prevents any form of open distribution, yet the license is open enough to remove most commercial incentive for maintenance and further development: a perfect recipe to make software instant abandonware upon release.
[1] https://essr.esa.int/license/european-space-agency-community...
Our research on GP models was based on Prof Rasmussen's GPML library[0].
At that time GPML was in fortran (or MATLAB?) but our simulator and training code was all Java.
So one of the senior researchers found a random java port on Github and just plugged it in.[1]
There are third-party repos built around FPrime as well as documentation and training materials available here: https://github.com/fprime-community