I’ve been a part of directly or indirectly a number of shared libraries with significant cost and development time. So here are my thoughts based on my experience internally and observations of the development community in my circle. Before you continue, remember, these are just my thoughts 🌹
Opaque usage
This is the model that you follow when you access some online API. Someone builds it / they maintain it.
This is honestly the most reliable way to provide services both internally and externally. This is also the model followed by amazon for pretty much everything they do (hence the large number of service offerings).
Libraries are not that different from other engineering / product solutions. You can definitely apply the same engineering practices you apply to products and APIs to shared libraries. You just view them as a library product. Your users are now developers, their bug reports are you customer tickets.
Open source
Open source is known to work. At least 50% of a modern enterprise depends on open source (this is a very conservative number, it is most likely more like 70%).
Yet I (and I am sure you) have seen it fail so many times when done internally in organisations. There are a few issues that pop up commonly in internal open source. A key missing ingredient, passion. A significant portion of the time that developers spend on open source, is after work hours. They use this to do things that are often not a part of user stories e.g documentation, code cleanup. These things often get overlooked in internal open source efforts.
Another common issue with internal open source, is the business expectations that come with it. When a developer uses true open source, they understand that this is a dependency that needs to be handled with care, and if it goes south, a fork / replacement is very likely. This understanding goes missing when business mandates an internal open source solution. More on mandating later. Short version: It doesn’t work.
One more issue with internal open source is lack of resources. When a team uses true open source, as far as the business is concerned its mostly a zero cost reuse. This is not true for internal open source. If there is an issue found in external open source, a few things happen. When your devs send a PR it has a higher chance of going through because the open source creators are passionate about putting a good face and keeping their public examples bug free. Also the business cost is that of the internal dev work for the fix. The cost of applying the fix is carried by the open source owners.
How to do open source correctly
If you are going to follow the open source model, do true open source. Put it on Github. Don’t be surprised when your developers start getting passionate about the project, cleaning up things, documenting its internal patterns and even sharing it on forums and conferences. All great things that make it easier to hire and retain quality engineers. Also realise that it is still a product, and you will need an internal dedicated resources maintaining and managing it.
An alternative option is to view all internal open source as a template. If you don’t have resources to spare, this is the way to go. If a team wants to build something on top and it’s hard to do in the current library, fork, send a patch, if the patch is accepted, great, otherwise continue on the fork. Once again, you view it the same way you would view an internal product or API. Request changes, but if that is not the direction the owning team wants to go in, fork.
Shared practices
Also known as no library (or multiple libraries). This is the most common pattern for existing enterprises. Frontend has come a long way very quickly — and probably still has a long way to go. How you do things today, might not be relevant (the most efficient — or in worst case even supported) two years from now.
If your enterprise business model is create and shelf projects (i.e. stop active development on projects after launch) then you will most likely have to go down the route of library per project (project here is a loose term — it can even be distinct business unit with multiple projects underneath them).
In this case, the library (or libraries) get rolled into the rest of the work the project team is working on and automatically/actively develops and maintains its purpose (help with project work).
This scales well as far as developers are concerned (after all a Frontend Developer knows how to style a button and attach logic). However for the enterprise it means that they will need more resources on hand per project per skill set. When time is the most expensive asset for the organisation (true for many large organisations), this is probably even ideal.
Footnote: How to lead tech
One thing that has failed time and time again is mandated technology choices. This is pretty much the best way to kill innovation.
Shared libraries should exist to make developer experience easier. No pattern of code sharing will be successful if you mandate shared libraries without evaluating developer feedback and realising that every library comes with a shelf life.
