Данила Риджи

1) Актуальность (читай востребованность).
2) Качество (без говнокода, без оверинжениринга, простое и понятное решение)
3) Встраиваемость (если прикручивание вашего решения займет больше, чем реализация своего -> понятно, что выберут).
4) Быть лучше более популярных альтернатив.
5) Развитие и продвижение. Фиксить баги, собирать фидбэк, пиариться в профессиональном сообществе.

В общем-то всё.

В первую очередь - опыт.
То есть, библиотека должна быть не маниловским мостом "отсюда и до петербурга" а базироваться, во-первых, на опыте разработчика в области, в которой он собрался осчастливить человечество, и во-вторых - на реальном опыте эксплуатации библиотеки, по результатам которого библиотека исправляется и дополняется.

В случае с валидатором форм все библиотеки разработываются по одному и тому же сценарию:
1. Богатый опыт подсказывает разработчику, что параметров валидации целых два: наличие данных и их длина.
2. Под эту парадигму пишется удобная, красивая, легкая, быстрая, аккуратная библиотечка.
3. Попытка использования в реальном проекте выявляет еще 100500 вариантов вализации и их комбинаций.
4. Разработчик пытается впихнуть в библиотечку все невпихуемое, и она закономерно становится толстой, уродливой, неповоротливой, с кучей неявных соглашений и хаков.