On Thu, Nov 20, 2014 at 5:00 PM, Jim Jagielski <j...@jagunet.com> wrote:
> It's a shame that there isn't a company like Covalent > around anymore that focuses on the Apache httpd web-server. > nginx.com shows kinda clearly that having a motivated > company behind a web-server helps grab market share and > market awareness (they can continue to beat the drum about > how fast and reliable they are, when so many benchmarks > lately show that 2.4 is just as fast if not faster in > actual response time, but we have limited ability to > do that, and most reporters see us as Old "news" and > nginx as the new hotness anyway)... > > So who wants to get together and create a company > around httpd? :) > (Pretending that you're completely serious for a minute) Decision makers are extremely comfortable picking parts of their technology stack that are backed primarily by one vendor (but are indeed "open source projects," even if not the most inclusive or vibrant) and have a mixed offering like that of nginx.com. That's both the way a business model can empower the creators to make a particular solution attractive as well as a pat answer to the question of motivation to maintain and enhance the solution in the future. Risk is mitigated by a philosophy of integrating components from many different sources, so it may not be worth much to analyze one particular component too deeply. (Follow the crowd but listen out for grumbling.) I don't think there's any benefit to technical squabbles between nginx and httpd proponents in this environment. The ecosystem for httpd is huge; there are uncountable programmer-years worth of available solutions out there in the "Premium httpd" space, so I don't see nearly as much business justification for the free/premium model with httpd as there is with nginx. At the same time, there's no ability (not that there is a desire) to segregate certain features into a premium version. A support model doesn't seem worthwhile; your users are probably on Linux and they can get a better offer for support coverage through their Linux vendor; and given that nobody wants to use something anyway if they don't anticipate that the answer is already on stackoverflow, quibbling about differences in quality of support probably doesn't help in many situations. I don't think we're an attractive solution in the most literal sense (did somebody say "seen as old and tired"?), even though there is a tremendous amount of development vitality. If I had the pile of cash to start a company centered around httpd, I'd want to fund these work items on the open source side immediately: * fresh, professionally designed web site (look ALIVE, look EVOLVING, look VALUABLE) * updated look for documentation, and significantly enhanced "User Guide" material; the latter is DESPERATELY needed to supplant the ubiquitous 1999-era (e.g., run-that-dynamic-language-in-the-server, pre-forking, etc.) "solutions"; we need to OWN the story for how to do X with httpd if X is at least moderately popular or is something that works particularly well with httpd; this is an area where we are suffering from having been around for so long; and once the material is available, lots of SEO attention * careful gleaning of requirements from all the reasons people give for using another solution (even seemingly innocuous comments on blog articles can give a valuable hints at a pain point), and prioritize these for near term solution * clear summations of direction for HTTP, SSL/TLS, application deployment, complimentary statements of direction for httpd and dedicated resources to carry it out, and regular status reports which are generally informative beyond the httpd groupie community * oh, and make it possible for 90% of the potential user base to be running 2.4.latest in several minutes without possibly interfering with existing software; user guide material (above) must support having the user's own application deployed behind httpd a few minutes later At that point it is easy for people to kick the tires, and a baseline is in place for the company to then pursue whatever wild idea somebody had for making money. ---- Given no such company and perhaps 30 developers with their own disparate means of keeping of coffee in the pantry, while potentially benefiting financially and otherwise from a healthier httpd ecosystem, how can we organize our apparently limited time to meet the more important goals? > Honestly though, how much of the uptake in nginx > do people think is actually due to nginx being "better" > or the "best" choice, and how much do you think is > due simply because it's *seen* as better or that we > are seen as old and tired? > > Pretty much all I can think of these days is the deploy-heavy-application-behind-proxy scenario. Overall, httpd is fine. httpd is generally there w.r.t. specific features in mod_proxy_X, but we have to expect that there will be a stream of small modifications needed in the near term to handle issues that had to be handled in nginx already. > This is our 20year anniversary... It would be cool > to use that to remind people! :) > We need a cute way to represent that the way you did things with httpd 20, 15, 10, and even 5 years ago is NOT the way you should do it now. Word clouds that fade in and out? .conf snippets that fade in and out? -- Born in Roswell... married an alien... http://emptyhammock.com/
