I had the same opinion in the past. But after some more years of work experience - mostly in the managed services area - I don't think it's that clear anymore:

I had the same opinion in the past. But after some more years of work experience - mostly in the managed services area - I don't think it's that clear anymore: - If you offer your users a library, you are competing with tons of open source libraries which claim to offer the same thing. A lot of those will be incomplete, buggy or insecure. But most potential users will never know and try to get them work instead of looking at your offering. - If you are offering a library, debugging and user support can at times be challenging. Do you expect user to look at the internals (source code) of your library? Provide core dumps? - Having to support N different [major] versions of libraries can become challenging. It's hard to know when all users have upgraded. With a service, you can control the update schedule. Even though changes to public APIs of the service certainly are still problematic. - Write a library - but in which language? You might prefer Rust, but your users might prefer Go, Java or Python. You could write the core in one language, and add wrappers in other languages, but some users will still be unhappy with it (e.g. because it makes compilation difficult, people don't want "unsafe C code" in their high level language project, or the wrapper might slow down performance). - Libraries which are general-purpose and are not targetting a specific application/service can over time become feature bloated since things are added "just for the case that someone might need it". This makes them hard to maintain. And since there's no feedback/telemetry, it's also hard to say whether something can be safely removed. Note that all of this doesn't mean "don't write libraries". Even if you write applications/services, its good to structure internal components into libraries. It's mostly about "what is preferrable to offer for users".