Slashdot Mirror
Open Source Course for Managers?
faqmaster asks: "I teach systems analysis and design as part of programming and project management tracks at a community college, and I'm interested in putting together a course for project-managers on open-source software. What suggestions would the Slashdot community have as far as what managers need to know/understand about Open Source? What books would you suggest? Anyone have any especially good case studies of successful OSS implementations in the business world? Any insight as to how project managers and the like can successfully incorporate open-source into thier projects? What advantages might they see? What are the pitfalls?"
Assuming you are up against the "free" prejudice (nothing good is free), one of main points of emphasis would probably be the quick release / report / revise cycle that a successful, widely used OSS product enjoys. Major (or minor) flaws are quickly discovered that might not appear during even a rigorous bug-hunt by the developers. Given that OSS makes the source available, any customization needs can be handled in-house if necessary - flexibility is the key .. would you
rather wait for a corporate entity to raise itself from the rust to release a patch or a new revision, or adopt an OSS product for use that allows you as granular a control as you need?
Without any overriding reason to use a non-OSS product, the choice would seem obvious, all other things being equal.
- How to get involved
- An email from an Apache developer that explains how he got started
- Project Guidelines
- Understanding Opensource
Yeah, ok I'm a karma whore. Still, if it helps this guy what's the harm?That which does not kill me only makes me whinier
First, I'm going to assume that what you're talking about is projects that use OSS, rather than projects that generate OSS.
At AdAce (shameless plug), I pressured my CEO to let me build the website on top of OSS tools and systems. It was a relatively easy sell at the time, because I (the CSO) and the CTO were both OSS enthusiasts, and we got a lot of respect from our CEO for our technical expertise. This wasn't one of those micromanaging CEOs that some companies have.
Now I'm both CTO and CSO, and I'm quite happy with the result of using OSS wherever possible.
The website linked above is built on top of Apache, Linux, GIMP, MySQL, mod_ssl, and smail. We use gcc and all the other g-tools to build the beast. (We wanted to use PNG for all our graphics, but IE's support for PNG is just too horrible.)
Our system has only two pieces using closed-source closed-source software.
The first is the library provided to us by our credit card processor in order to communicate with their systems (signio, now bought by verisign). But that library was built using ssleay, and knowing that I was able to patch up the binary library to avoid certain SSL attacks against us. (thank you, ssleay!)
The second piece is our ad servers (realmedia). We chose closed source ad servers because we needed a certain set of features, and the OSS ad servers out there are too far behind in that feature set for us to use them. We could have added the features we need, but that would've but a huge engineering burden on us that we couldn't afford at the time. Now that we've come far enough, we're evaluating the current OSS ad servers to see which one we're going to adopt, and add the features that we need (and, of course, commit those new features back to the project).
The selling points that we used to push the OSS point are:
1) The security of an OSS project is superior to the security of a closed source project. This is because either the security holes are found by other people and patches are submitted back to the project, or I (whose duty it is to analyze our security) can find the problems and fix them. While with a closed source project, this is all dependent on the very busy engineers at the software's vendor, who will always prioritize security below where we would want it prioritized (we want it to be the #1 priority). It's so nice to be free of worrying over priority conflicts between us and a software vendor.
2) The stability is superior for the same reason.
3) Licensing fees are trivial. For most OSS projects, licensing is a voluntary donation to the support organization, and the size of that donation is up to us to determine. For other OSS projects, licensing is free. The only real exception is MySQL, which has specified certain donation levels which, nevertheless, are far lower than competing database software's license fees.
4) When (not if) the vendor of a closed source project moves on to other projects, and abandons the software that we're using, we're screwed. But if we use OSS, then we've got the source code, and can continue to support ourselves. Plus, when that happens, we've developed enough internal expertise with the software that it's not too difficult for us to support ourselves.
Apache, in particular, has been a huge boon to us. It's so easy to write modules for Apache that we've got our server packed to the gills with custom modules to perform certain session management and dynamic content tasks for us. These have improved our website's speed and maintainability by a huge margin. (some of these modules have progressed far enough that we're nearly ready to contribute them back to the Apache project.)
In hindsight, we made one big mistake with our OSS work. That is, whenever we brought some new OSS project on board, we would assign it to one engineer, and that engineer was to become our expert on that system. We spread this load around so that no one engineer would be overburdened. But what we should have done (in addition) was to have a "debriefing" a couple weeks after the assignment, so that that engineer could brain-dump a portion of his expertise into the rest of us. As it happened, we had engineers leave us (which is the usual case in engineering) who were the only people with expertise in a particular piece of the puzzle. And when that happened, we were left scrambling to redevelop the lost expertise. It all turned out ok, but it might not have.
These days, as a large result of using OSS wherever possible, we're in a very good position. Nearly all of our competing ad networks have abandoned the market for greener pastures, and that includes every ad network that's bigger than us except for 24/7 and doubleclick. The other big guys have switched to licensing their proprietary ad servers to other ad networks. As a direct result of our adoption of OSS, our total monthly technology costs are trivial, and we can survive comfortably on a truly tiny number of sales in a month. Having leaned heavily on OSS software, we were also able to focus a lot of our engineering on automating the administration of our system to a large a degree, so our administrative burdens are also tiny. This is letting us ride out this deep depression in our industry without worries, and when things turn around we'll be in a very enviable position.
The only downside to OSS is that there are a large number of licenses to read and discuss with our legal department. This number is, of course, similar to the number of licenses that we would be under if each individual portion of our website used equivalent closed source projects. However, closed source projects tend to bundle multiple pieces together under a single license, so we would actually have fewer pieces (and hence fewer licenses) if we used closed source. What's worse, many OSS projects use licenses that are superficially the same, but contain modifications that are specific to that project. So, though it's tempting to read the opening clauses and conclude that the license is the same as this other license that we already analyzed, it's foolish to do so.
But the bundling phenomenon of closed source projects is actually a disadvantage. Since no closed-source project satisfies all our needs, we would definately need multiple. And if different closed-source pieces overlap in their bundling, then either we have to reject a piece that we'd like to use, or we'd have to find a way to disable the pieces that we don't want to use. That's always a pain.
-- Nolite audere delere orbiculum rigidum meum.