Feature implementation policy

[Maxim Dounin]

Hello!

On Mon, Feb 26, 2024 at 11:13:55AM +0330, Reza Mahdi wrote:

> In the nginx project, some sort of features where rejected with certain reasons.
> For example FastCGI multiplexsion, or HTTP/2 reverse proxy both where rejected
> with this reason that their backends are in the same machine as the server.
> 
> The reason IMO is NOT acceptable in all situations. I wonder if this type of 
> policies will be continued in freenginx as well?

Overall, I wouldn't expect major changes in the policy here.  
Except might be I would expect freenginx being more open and 
public in decisions and discussions, something I always tried to 
advocate for when I was an nginx developer.

Still, I don't think you understand the existing policy well enough.

The general policy is as follows: it's developers who decide if a 
particular feature should be implemented or not.

Such decisions are usually made based on developers understanding 
about expected use cases for nginx in general, use cases for the 
particular feature and potential benefits from the feature in 
these use cases, as well as resources required to implement and 
maintain the particular feature.

For example, requests to implement forward proxying in nginx were 
traditionally rejected, because nginx is not a forward proxy, but 
a reverse proxy.  Forward proxying is a completely different use 
case with quite different requirements and security concerns, and 
even if implementation to some working extent might be simple 
enough, maintenance costs are going to be high, distracting 
developers and blurring focus of the project.

If you are not happy with a decision about the particular feature, 
you can always discuss it and try to convince developers that it 
needs to be implemented, either with arguments, such as by 
demonstrating use cases and resulting benefits, or by providing a 
good implementation.

-- 
Maxim Dounin
http://mdounin.ru/