I think it could be valuable for us to establish some form of an RFC process for proposing and developing major new features. I also want to avoid being too process-heavy here as that would also disincentivize contributions. I agree that we should try to be more data-driven to determine what features and products should have the most attention.
I do like the idea of having “sample” plugins which are not distributed as binaries, though, which can be used in documentation for examples of how to integrate your own systems. With the flexibility of the plugin system here, we can defer the implementation of more obscure integrations to the end user. I will note that we do already have some level of filtering to what we include. I’ve proposed numerous features in the past that I didn’t pursue due to reasons raised by others or lack of interest. > On Sep 29, 2023, at 2:59 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > 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.
