Talk To a Successful Free Software Project Leader 150
Nagios (formerly known as NetSaint) is a GPL network monitor software project that's been getting a lot of buzz lately among *Nix sysadmins. Nagios is unquestionably a free software success story even if it's not as high profile as Apache or Linux. Ethan Galstad leads the project. Perhaps he can tell us why Nagios has done so well, so that other free software projects can enjoy similar success. Usual Slashdot interview rules; post your question below, we'll email 10 of the highest-moderated questions to Ethan about 24 hours after this post appears, and publish his answers soon after he gets them back to us.
Re:what it is (from the official site) (Score:4, Insightful)
That's great for interactive use, but Nagios (along with Big Brother, and most other monitoring packages) doesn't seem to cater well to automating report generation from outside of a web browser. We need to generate weekly reports on the number of outages, etc., and would like to be able to schedule a cron job every Sunday night to say "get me the uptime stats for abc services, so I can put them into xyz reporting package". We need to take the raw data and calculate rolling averages, etc, to give to customers (we're contractully obliged to do so). I.e., the sort of reports we need are typically more complex than is reasonable to expect Nagios to do internally. Was the interactive bias a deliberate decision, or did it just evolve that way. More importantly, are there any plans to improve things in this area?
mass-appeal software (Score:5, Insightful)
Re:How is a project like this supported? (Score:3, Insightful)
Uh... riiiight.
I'm sure he has the authority to tell a programmer to shelf whatever they're working on and fix this bug... presuming it is a bug and not just a config error or something. Since the programmer has absolutely zero familiarity with the source, and probably none with the program at all, it's going to take some time to figure the bug out. Even given an above average coder who is familiar with all the necessary tools, it would take at least a couple weeks to figure out the code and fix.
Presuming that said above-average-coder is being paid only $80k, two weeks of their time is worth $3k in salary... which means about $5k once you add in benefits. And you've just delayed some other project -- one that is actually related to your core business -- by 2 weeks or more (probably more - it takes time to gearshift). That delay could cost the company an unknown amount of money - anything from $0 to millions, depending on the importance of the project.
Oh, and lets not kid ourselves. Programmers in large corps (and most small corps) don't work in a vacuum. Most have teams that interact with one another as well as other groups. Pull this senior programmer out of that and you're going to delay all of them too.
Now, how exactly do you justify this to management? Versus just buying an off-the-shelf solution, which -- even at $50-100k may -- be cheaper than tasking a coder to something that's tertiary to your core business.
To some extent this is a worse-case-scenario. To some extent its not. But having the code available doesn't mean jack shit in the real world, because it still costs huge amounts of money to get it fixed. Most successful (as in adopted by businesses) open source projects realize this and provide paid-for support -- because most companies know it's worth the time to pay for support rather than spend their own resources fixing it when something goes wrong.