My experience with sharing components in the company has not been a good one. I don’t think its so much the method of sharing that is the problem which this article tackles and promoting their app as well, but just the concept will not work depending on the company.
I worked at a fortune 500 company where someone had a novel idea. They saw that most of our apps contain the same kind of components like tree navigation, data grids, etc. and thought why not have a special team to create a library so the entire company can use? Stuff like this looks great on Power Point and I have no doubt this person got a big bonus for this idea but the execution is another thing and after a year or two, this project was entirely abandoned.
There were several things that went very wrong. For starters, you need a team that are exceptional developers. The ppl that contribute to open source are rarely the casual 9–5 programmers. They are true software developers that love their craft and excel at what they do. Creating truly reusable components not only requires fast performance and maintainable code but bullet-proof testing because you need to cover every scenario imaginable or else it’s not truly reusable. The team that was doing this couldn’t even give us performance and so when other teams started using this library, they were immediately turned off from it because it was very, very slow. The performance improved eventually but not by a whole lot. But by then, trust was lost from within the company. Nobody trusted this library. They instead chose to develop themselves within the team with better and sharper developers. The first rule in creating a truly reusable library: first impressions matter. If it sucks on day 1, you lost everybody’s trust and to regain it is near impossible.
Lastly, the API docs for this library was awful. It was just some screenshots and a few lines of text. Examples were badly needed as well as making the font size bigger and improving other visual elements of the page to promote readability and want to make the developer spend time there because they will be spending a lot of time there since they don’t know how to use this component. When API docs are always outdated and not clear, you can bet this will be the final nail to the coffin of this library.