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?"

Comments

What companies need for open source

[Chardish]

Comments in the source-code are the most crucial thing for any serious company looking into open-source...if they want to customize their software they need to be able to understand it.

-Chardish

Just This:

[Rosonowski]

That it's not this big evil thing that companies such as Microsoft make it out to be. That the software is not as buggy as the salespeople for large firms tell them, that in fact, a great deal of it is so well supported that in many cases, it is much more stable then windows.

Now for buzzwords. They need to hear that it is scalable, robust, and will boost productivity.

And they need to know about programs such as StarOffice That are in a great many cases, better then Microsoft Office, along with offering compatibility with existing systems. In short, there's almost nothing that a large firm puts out that cannot be replicated in an open source enviroment.

The usual "Why ask Slashdot?" answer...

[wrinkledshirt]

Start interviewing project leaders of popular software titles at Freshmeat or Sourceforge.

OSS in The Real World

[ixo111]

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.

Deploy or Build

[cullenfluffyjennings]

Many companies, including Cisco where I work, have made strong use of open source software and deployed it extensively - this is different from developing it. Make sure you deal with them separately.

All the problems that exists in traditional software development, also exists in open source plus some new ones because of communication and distributed control issues. It's not like you can easily fire an open source developer (and that is good :-)

Let them in slowly

[Telex4]

I've been slowly integrating GNU/Linux into my company, but it's been a struggle. I work in an IT training company who are used to Microsoft fulfilling all their needs. They've become so used to Microsoft, their fees and their wide range of integrated products, that the notion of going with something as radically different as open source or free software just seemed ridiculous to them at first. No matter how many big names I mentioned (IBM, Sun, the EU), they just thought it wasn't for them.

I think that to start with, The Cathedral and the Bazaar is a good read. Though it's a little outdated, being somewhat in the dot-com mood, it offers some well reasoned argument behind using open source methods alongside more traditional business practices. But the real hurdle is convincing people that software written by "amateurs" (because that's how they often see unpaid programmers, unfortunately), and distributed for free, can be reliable and powerful. You also have to impress upon them how easy it is to integrate open source with their current goods, to get them out of the mindset that offices have to have Microsoft-everything.

One thing I would say is that most managers, unless they're in financial difficulties, don't jump at the "it's cheap" idea.

Re:I disagree

[sinster]

When I was in college, I worked on a research project for surface routing of multichipmodules. I wasn't actually one of the researchers, I was just there to code the user interface that went on top of the actual research project.

A major part of the user interface was clicking on vertices in the routing layout and dragging them around. When you have 10,000 vertices visible in the window, this can get obnoxious if you don't have a good and unambiguous selection mechanism.

Unfortunately, when I came on board, we had a bad and ambiguous selection mechanism. :(

We had weekly meetings of all the coders (that includes all the grad students who were doing the actual research) and we'd discuss new ideas. I'd seen a whole lot of ideas get passed around at previous meetings, and no matter the idea, it was always met with grave resistance. People wanted feasability studies, analyses, reports, blah blah blah. It was nasty. Far worse than any company I've worked for since, but that was academia, so it's not surprising.

So before presenting my new interface, I coded it up (took me 4 hours) and put it into the standard build. This was on a Tuesday. So for 3 days (Wednesday, Thursday, and part of Friday) people were using my new interface without realising it. I noticed a distinct change in the character of the conversations going on. But the change was subtle enough that no one immediately came to me to discuss it. Previous to my change, there was always a lot of grumbling and cursing whenever someone selected the wrong vertex, and all those stopped suddenly when I installed the new interface.

Friday came and I presented my new interface idea. People were very down on it. They wanted studies. They wanted an analysis of the time it would take to code it. They wanted references to existing peer reviewed user interface studies. Blah blah blah. I knew that would happen. So then I dropped the bombshell. I explained that I already coded it, it took 4 hours, and they've all been using it since Wednesday morning. The expressions on their faces and the stunned silence were precious. Apparently they were going over their use of the UI in their heads over the past few days, because shortly the room erupted in very complimentary discussion all around.

Of course I was told not to do that again, but I considered it an unqualified success. Not only did I get my new mechanism into the project, not only was the new mechanism successful, but I also managed to show everyone how damned bureaucratic they were being, and how much damage they were doing to the productivity of the project.

It was beautiful.

The point of this story is that a successful feature depends much more on the end result, not on the process. The function is far more important than the process. Sure, the process is important, but when you find yourself sacrificing functionality for the sake of process, you've just lost the war. Clear coding is nice. An architecture document is nice (I agree that a well thought out architecture is essential, but that is different from a well thought out written architecture). But they are both pale shadows when weighed against the final product.