Slashdot Mirror
Apache Comes With Too Much Community Overhead?
drizzle writes "There's an interesting story on the Apache Marketing blog about whether or not Apache projects come with too much overhead, especially compared with other services or a roll-your-own approach. The article states, 'It's true that compared with SourceForge, Apache has a more rigorous management structure. The ASF has formalized processes and procedures that we believe represent best practices governance. All new projects must pass through an incubation period to ensure that all of the project's members have internalized these processes. However, each project's leadership has a tremendous amount of discretion in managing within this framework.' There is also a follow up article written by one of the httpd developers about 'What Apache brings to the table.' The article cites community, experience, legal framework, diversity, brand strength, and networking as reasons why developers and companies should consider bringing their projects over to Apache."
You want to do a project? Okay, well nobody is forcing you to work with Apache. The Apache community keeps consistently turning out good products. This tells me they're doing something right.
Yeah, so with sourceforge you don't have to spend as much time on organizational matters. And also on sourceforge 98% of the projects are stalled out in the planning stage. I don't see an improvement there.
There is always room for self reflection and improvement.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I have this feeling that most of the stuff that you complain is hard to configure with Apache, that you couldn't do this with the lightweight stuff at all.
For simple stuff, what is so difficult about setting a port and a base directory?
I'm still trying to figure out what people mean by 'social skills' here.
No, I think the analogous observation is that Microsoft must be doing something right, because they've created the most popular operating system software (and probably software, period) ever. Which is true: they are doing something right. That something might be nefarious business practices and ruthless leveraging of a monopoly, but they're obviously doing a good job of it.
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
Yes, Apache (Web server) is somewhat hard to configure. There's a large file with a lot of (documented) features and settings, and a lot of ways to go wrong there.
On the other hand, Apache is incredibly flexible: You can use it as a proxy, it does ssl, it fronts for Java Web servers, it rewrites URLs, it authenticates, it slices, it dices and I'm probably just scratching the surface.
Someone who knows his way around the config file - and that's really the only crucial thing to know about Apache - is able to get it to sing and dance. The header in the file warns people to read in-depth documentation rather than relying on comments in the file. There is documentation, there are books. If you're going to play at being a 'professional' Web admin, then you need some of this stuff.
For the less seriously inclined Web maker, programs like Webmin let you fiddle with a subset of Apache settings through a HTML front end. On an even broader front, many Web site hosters provide a dumbed-down interface that allows only a small subset of configuration options and keeps the user from doing anything really stupid.
And for anyone not covered above, yes, I'd recommend getting a simpler Web server. Personally, I find Tomcat a little easier to configure than Apache, but that's just me. I'm sure there are dramatically simpler products. Hell, lots of people have written their own!
The discussion in this topic is not about the complexity of using the Apache Web server, but the complexity of managing an Apache project. I'm not sure if I'd be perfectly happy "doing" an OS project under Apache, but... that's what choice is about, right?
When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
It may be just me, but I think you're reading too much into a Netcraft report here. Outside of the fact that FreeBSD and Linux seem to be about equally present here, the platform on which the projects's *website* is hosted doesn't say anything about the platform the project itself is developed on.
Case in point: openbsd.org is hosted on Solaris. Does that mean that OpenBSD is primarily developed on Solaris? Of course not. And the same thing goes for Apache, too. It's still possible that Apache is primarily developed on FreeBSD, of course, but a Netcraft report doesn't say anything about whether it is.
quidquid latine dictum sit altum videtur.
Out of curiousity, did any of the above posters actually read the article? Or even the Slashdot post?
This isn't about Apache's Web Server at all. It's about the Apache foundation, and running projects with them. Apache's web server is just an example of a project that is run under the Apache Foundation... and any bloat / hard configuration in httpd has little to do with Apache Foundation's "overhead".
That comparison chart was last updated in 1998. It's woefully out of date.
Mod parent down.
You have to be kidding me? XML? Are you out of your mind? Apparently you've drank the XML koolaid and you're parroting it's usefulness for everything but ending world hunger. Almost every OSS project I use relies on the ease and simplicity of text configuration files. Of the few XML configuration files I've ever used, I've been left with a disgustingly horrible taste in my mouth afterwords.
Some of use don't want some GUI to do our configurations, and we certainly don't want to be at the mercy of one. When the GUI breaks or doesn't work (It's KDE only, it's gnome only, Xorg isn't installed, one doesn't exist yet, the ones available don't support these new options yet, ad infinium), we don't want to have to construct super perl scripts with XML capabilities to do mass changes in configuration files. Some of you might be fine with your tomcat's server.xml file being 1500 lines and the accompanying bloat, but I for one choose less complexity, even if the only advantage is controlling configurations more efficiently.
I'm not going to bash the Apache Foundation or Apache Developers, or even Apache itself. It's all good work, and lots of it, while I sit around doing SFA...so who am I to bitch?
However I believe that any bloat, be it at the Foundation, or developers, development, or Apache is all part-and-parcel of the Kitchen Sink mentality of computing.
I was going to blame the Linux community's Kitchen Sink mentality, but then I remembered Microsoft and their products (and just about everybody else) and realised that it's a computing thing, not platform specific.
Ever asked somebody to do an install for you, either because you don't have time, or it's new to you, or whatever? They will always install every last little thing, "Because you may need it someday".
I'm a minimalist when it comes to systems, and I mean minimalist: unless the system won't function without something, it's not installed. Yet I have never met anybody else with the same approach.
Humans and bloat go together I guess.
You are making your company dependent on the GOOD WILL of others.
Quite to the contrary: with OSS, you are not dependent on anybody.
The real thing you should worry about is that with closed source software, you are at the mercy of your vendor.
However it all functions perfectly under Windows and Mac OSX.
I'm typing this from a Mac OS X laptop--which I just had to reinstall because it was dying with a kernel panic during boot. Before that, it failed to read the xD cards from my new consumer digital camera. And among many problems, file associations are inconsistent under OS X, the green resize window button is unintuitive, and the Finder views switch haphazardly. The point is that even the best desktop operating systems have problems--Linux, OS X, and Windows are comparable in that respect. If you claim otherwise, you're simply trolling.
IMHO, the Apache group has gotten a little too comfy with their market dominance and years of blind faith from unix users. Sounds like it's time to remind them that especially if you're already on an open-source platform, you have a lot of choices.
Yeah, they need a message. Look at that beautiful graph now - Apache's hit 70% this month!
Obviously, they're hitting that percentage because, like, people don't have a choice in the matter. It must be dirty pool playing on the part of the ASF... right?
I find the Apache config file fairly easy to set up. It works reliably and without complaint every day, with now just shy of 5 years of perfect uptime...
Of course, you might consider this option... Pick your poison.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
You have to be kidding me? XML? Are you out of your mind? Apparently you've drank the XML koolaid and you're parroting it's usefulness for everything but ending world hunger.
He's not out of his mind, and you aren't proving your own sanity by being rude. There's nothing wrong with XML for configuration files, and plenty to gain. If you have config in XML, developers can write config integration or front-ends in any language that has an XML parser. PHP, Java, Perl, Javascript, Python, Mono/.NET, etc., etc. With normal text config files, you have to do ugly string manipulation, and you have no way to adjust from version to version without custom hacking for every setting in the config. This is why front-ends rarely exist for most text config files, and why front-ends do exist for many XML config files.
Further, with XML the configuration option and it's set value can be validated. Right now, we don't know if any setting in a text configuration is actually doing something or doing what we want. From version to version settings change, go away, gain new options, etc., and we have no way of knowing if our setting is valid until we view documentation - and even then we have to hope the documentation is up to date.
Some of use don't want some GUI to do our configurations, and we certainly don't want to be at the mercy of one.
No one is forcing you to use a GUI front-end for XML config files. But thanks for thinking that you are the center of the universe, and all those who want a front-end be damned.
When the GUI breaks or doesn't work (It's KDE only, it's gnome only, Xorg isn't installed, one doesn't exist yet, the ones available don't support these new options yet, ad infinium), we don't want to have to construct super perl scripts with XML capabilities to do mass changes in configuration files.
Editing an XML config file in a text editor isn't harder than a non-XML config file. The same "stuff" is there. Yes, it has tags around it that take up space, but big deal.