How open-source library should allow for almost every kind of customization 🔧

Any feature in your open source library will be customized sooner or later by someone in a way you never dreamed about. And there is nothing worse for your library consumers than realizing that your library doesn’t allow for X, when they desperately need X. You should somehow allow for almost every kind of customization. But you need to find a good balance: how much you implement vs. how much you force library consumers to implement.

Common customizations

Every common type of customization should be supported by a simple configuration. It’s for consumers convenience. The more they are happy with your library, the more popular your library might become.

Probable customizations

Less frequent type of customizations, but still quite probable ones, can be unsupported by default in your library, but they must be feasible in an easy way. For example you might expose an extensibility mechanism that require a consumer to write a little custom code (i.e. overwrite a default method).

Edge cases

Edge case customizations must be also reachable, but you’d rather not invest time to implement them in your library. Just ensure that there exists some extensibility mechanism that allows for that edge case. It’s fair enough that it forces a consumer to write a lot of custom code (i.e. overwrite one or few whole classes).

Don’t implement too much!

You should not implement every feature requested by the community members, but only the most often requested features. For less frequently requested features, just expose extensibility points. Supporting too many edge case customizations by default might result in unpleasant consequences both for you and your library consumers:

• more complex shape of the public API (i.e. owerwhelming configuration) - less convenient for consumers
• more complex source code - harder to maintain
• need to test and support more things at the same time (including cross-feature compatibility)
• need for a bigger documentation
• enlarging the surface of the public API. When it's too big, it’s more likely you'll have to make a breaking change just to fix a small bug (beware that library consumers are not fond of often breaking changes, but like bugs to be fixed quickly).