I want to challenge the current way of PMC determining the product feature set and work towards a more sustainable alternative.
Logging Services team... - delivers mission-critical products that are deployed at the core of the world-wide infrastructure (actually, in Mars too) - is short on development resources compared to its wide range of offerings - deals with substantial amount of legacy - suffers from knowledge silo Any IT team in this state would be really conservative on accepting new features and try hard to get rid of the bloat. They would react to this challenge by first discovering the user base, pinpointing the core values, and then lazer-focusing the limited development resources on to the crucial deliverables. Though we do something totally different, one can even say the opposite. Below I share excerpts from recent mailing list posts. *"I had added [X] ... to show how to write plugins and for some consulting-related use cases"* – PMC member explaining how feature X was released *"... stuff seems like it could be useful"* – PMC member asking to keep feature X *"my employer used [X] ... for anyone implementing ... this would be very relevant. By archiving this we are basically telling users that they cannot use it any more since it will no longer be supported. For that reason I am not in favor of [retiring]"* – PMC member asking to keep feature X *"We [the employer] ... use [X]"* – PMC member asking to keep feature X *"User base [is] ... very low to non-existent."* – PMC member asking to keep product X *"[PMC member] has steadfastly [reacted] ... and until he positively says he will no longer maintain it I am not willing to override that"* – PMC member asking to keep product X because another (one and only) PMC member reacted on product retirement inquiry *"Our employers are ... paying customers."* – a PMC member explaining why we should keep feature X used by an organization employing another PMC member I see a pattern in the way we decide to maintain a feature/product: - It is not data-driven. It is disconnected from its user base. No usage statistics, etc. is shared or used. - We serve individuals' and employers' agendas. - We underestimate the cost of adding/keeping a feature. I think this diet is "unhealthy" because: - It adds up to the bloat. It is yet another component developers need to maintain its dependencies, documentation, website, integration with the build system, etc. This bizarrely slows down the development experience. (Ever wondered how much `log4j-osgi` takes during `./mvnw verify`?) - It adds up to the attack surface. - Features that are supposed to be optional get shipped to users without their consent. (Consider the percentage of the Log4Shell victims that used the JNDI functionality at all.) - Scarce development resources get wasted on chores due to the excessive landscape. - It gives users the wrong impression that the feature/product is maintained, though under the hood it is just kept there because a privileged group wants so. I want to refine this approach with your help. To start the discussion, I propose the following strategy instead: *"We only accept a feature with data-driven justification."* – Have a brand new idea? Grab yourself a GitHub/GitLab repository that belongs to either you or your employer, knock yourself out without any ASF/PMC burdens, and amaze your users. Once the user attraction gets enough gravity, let's discuss blessing it as a part of the official Logging Services offering. Official support channels are always open to assist the developers of such external efforts. *"We only keep a feature with data-driven justification."* – Do you think a feature needs to be retired? Bring it up for discussion. PMC should evaluate the request based on numbers and this process should be independent of the individuals'/employers' agendas. If PMC decides to retire a feature/product *and* there are people who volunteer to continue the development on a successor fork outside of ASF, PMC should do their due diligence to point existing users to this fork without any endorsement. I look forward to hearing your thoughts.
