Alternatively, if companies know they can&#x27;t use Go for libraries unless they&#x27;re willing to make their source readable, and there&#x27;s customer demand for Go, maybe they&#x27;ll give in.<p>A decade or three ago, it was common for <i>all</i> software not to come with source code. If you bought some server software, the client library was closed-source as a rule, if it even existed, regardless of how enterprise or non-enterprise it was. Now it&#x27;s not uncommon to see even closed-source services have client libraries on GitHub because that&#x27;s where they&#x27;re expected and that&#x27;s how people expect to publish client libraries. That change seems to have been good for the industry and good for the world.<p>The enterprise users will come along eventually. They always have; you can find articles as recently as a decade ago debating whether your company should allow the <i>use</i> of open source software internally, or have a blanket rule against it. The second option is now inconceivable for almost all companies, because you put yourself at such a competitive disadvantage. All Go needs to do is deliver a technically attractive product, and people will figure out how to be comfortable using it.