On 4/18/2018 11:46 AM, Jim Jagielski wrote: > IMO, this boils down to 2 things: > > 1. nginx, particularly, does a LOT of promoting, marketing, PR, etc... > We don't. They get to promote their FUD all the time and remain > pretty much unchallenged.
Speaking from experience at $dayjob, I can confirm that the marketing and sales folks are out in full force. I and a colleague have both been contacted at our work addresses with messages tailored to our cloud and cloud native jobs. Editorially, my work email address is not published publicly - so this requires at least some minimal thinking to figure out what the address is and to send the right targeted message. At the same time, we should acknowledge that there are some things these other products do well. TCP proxy/loadbalancing seems to be present in many proxies but not httpd. Most products do not expose users to underlying implementation details and instead allow the administrator to express what they want done (the example that comes to mind is slotmem/proxy modules needing to be loaded or a semi-confusing error will come up). Some have really great 'how to' pages on their main docs site to keep people from needing to dig. > 2. They don't seem to have issues in understanding that new features, > enhancements and improvements to the server is what keeps users > and grows community. Instead, we either spend our time naval > gazing and pondering such inane issues as revisiting versioning, > or else treat the codebase like a school exercise where the > winner is the one who changes the most number of lines. Each time > a new feature is proposed, we have to deal with the incessant > blather around 2.6, 3.0, EOLing 2.4, blah blah blah. We've had > some features in httpd long before similar functionality existed > in nginx, for example, but they got to release 1st because we > were too busy standing on soapboxes or bike-shedding. I think it's fair to point out that we have shipped regressions in some form or another for several of our recent releases... plus a few that didn't get shipped thanks to the n00b RM :-). I can't speak for every contributor to the code base, but I view breaking or significantly altering a configuration that is working today to be criminal. Given that we have made mistakes, the conversations that are being held are both an acknowledgement of the errors and brainstorming about how we can proceed without harming our users. We want to release new features AND remain stable AND improve the code base. There is a balancing act among those three goals we need to agree on as a community. I'll use this blank line as a quote for what I think could possibly be a third point for consideration. We are lacking in two areas that I think are key for survivability: enterprise usability and machine-based management On the enterprise front: one of the things that Microsoft gets right is that with enough clicking around in a UI, an administrator can accidentally implement a perfectly functional server. The massive amounts of study put toward usability and consistency pays off since an admin who understands how to generally set up a windows server could just kinda figure out how to start and manage the web subsystem. Talking about nginx in the enterprise, you don't get that same level of "clickability"... but you DO get a phone number you can call and complain to when your config isn't working right as well as some pre-sales/post-sales engineers that will help you through the configuration syntax. On the exact opposite front: IIS and nginx suffer just as badly as we do when it comes to machine-driven management. There are pretty clear trends happening in the world around aggregating several OSS projects into a larger amalgamation (Kubernetes being a rather fine example). These amalgamations tend to prefer services which can be configured by a machine both pre and post start. In the proxy space, envoy is a big up-and-comer where config can be read from file but completely altered via API after the server has started. Having a machine-friendly configuration syntax (YML or JSON, for example) would be a great gateway to constructing a generic API handler that can modify nearly any part of the running server. To be fair... I think these are cool things to do, but FAR beyond my skill set and time budget. > Personally, I'd like to see the the PMC take a more active and > direct role in addressing #1, maybe w/ monthly blog posts > coordinated w/ Sally. It would also be cool to reboot Apache Week > (I know it was an external, 3rd party effort) in in conjunction > w/ the blog posts or instead of it. This is interesting. Can you provide some examples for the types of blog posts that you think would be good to make? Stealing from other parts of the thread (thanks, Luca!), I could see value in providing bite-sized tidbits of how requests/responses are run, what this whole "hook" and "pool" stuff is all about and anything to demystify the filter chain. Those things could also be used to refresh our developer guidelines pages. I'm not positive that kind of content is what you have in mind since I think that would primarily drive the interest of module authors rather than the folks who choose which webserver to use. > And finally, when the vast majority of web servers nowadays live > *behind* proxy servers, these type of metric surveys are meaningless. > Of course, I feel that this was nginx and MS' plan all along: they > knew how things were changing and wanted to win the "proxy server > market"... all that should be pretty obvious w/ 20/20 hindsight. -- Daniel Ruggeri
