We shouldn't just blindly throw in new features, now matter how small they are. Most
mature projects out there probably have more undocumented and unused features than they
have documented and used.
Having a rule that all features should be documented and tested goes some way to prevent
this. If you can't be asked to document and test something, chances are we don't
Besides that, I'm a strong believer in "the team knows best" so most things,
no matter how small they are, should be mentioned on the mailing list IMO.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
Sent: Friday, 5 December, 2014 2:57:15 PM
Subject: [keycloak-dev] vision vs. infinite configurability
Users want Keycloak to work like their existing solutions. Users have
peculiar use cases they need to solve. As engineers, we want to satisfy
our customer's needs so we add option after option.
This worries me...
We have to constantly think about the Keycloak "vision". We need to
continually think about how users *should* use Keycloak rather than how
they want to use it. Every time we add a new configuration option to
keycloak we add complexity. We make keycloak harder to understand and
use. We need to keep this in mind as we go forward over the next few
months. When customers ask for a new feature we need to ask them or think:
* Is there an existing way to do this?
* Should we allow this option?
* Is there a better way to solve the customer's need?
A big one is: Can we enforce specify policies to make Keycloak easier to
configure? For example, as a SAML IDP, we can say, sorry, but any SP
needs to be able to handle signed saml documets. we don't need to
provide the config switch to not sign a document. Get what I mean?
BTW, this is why I get so pissy whenever you guys want to add another
SPI or config switch. I know how these types of things snowball as a
project ages. You can collapse under the weight of them. Having a
"vision" helps tremendously as you tell users how they should be doing
security rather than just doing whatever they want.
JBoss, a division of Red Hat
keycloak-dev mailing list