What it means to be upstream

Upstream is not a set of rules.

The linux kernel was written by a dude, without Git, and without Github.  The requirements weren't specd out by a committee.  Kubernetes was built at google - and donated afterwards.    Hadoop was built by a guy over a weekend of reading a whitepaper, and then named after a stuffed animal.  Mainstream Hadoop vendors still name their products after hadoop.  Meanwhile Kubernetes vendors sometimes do (and sometimes don't) name their products after kubernetes.  There are no rules to be found anywhere.

As an example, looking at Centos, theres no 'real' separation of RHEL and Centos that is actively managed:

So what does it mean to be upstream ?

To me, it means you hack, share ideas, and innovate in the open.  You're not afraid of trying new things, and your not afraid that your 'code' is of value.  You know that the community behind the ideas, your ability to proliferate those ideas, and your ability to share those ideas in working prototypes with internal, and external users, at a pace which responds to requests with a minimal amount of bureaucracy and a maximum amount of sensitivity to user's stated needs - are all the things that really matter.  Everything else, including software architecture, bugs, codes, policies, conventions, are just implementation details that change from day to day depending on who the alpha coder is on your project - and generally - enforcing them inorganically, even if they are 'for the greater good', is really a waste of time when compared to the cost of decreasing the velocity of your teams ability to put ideas into customer's hands.

There are risks associated with this.

There are huge risks associated with breakneck innovation. Which is why startups do it, and big companies don't.  And big companies just buy startups.  The best way to have a great career as a programmer , is to obsessively build the type of stuff that big companies are afraid to do on their own.  To me, thats what the word upstream means.