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.

Great Tips I've Discovered

[ekrout]

Keep teams streamlined. By consolidating work into a smaller group, you can reduce the number of necessary meetings and the amount of time spent trying to keep everyone informed.

Define terminology. When you begin working on a project, nail down work-related definitions and make sure everyone involved understands them.

Document decisions. Any time you and your team makes a project-related decision, write it down. Include an overview of the rationale behind the resolution.

Group project deliverables. For long-term or ongoing projects, you can reduce project-management administrative burdens by delivering work in batches.
This will reduce the number of times that you need to contact your client and will allow you to consolidate feedback sessions and next steps.

Rework notes immediately. After you finish project meetings or phone calls, review your notes immediately and fill in details you remember from the session but did not write down. At the same time, make a list of next steps and mark the date they need to be completed on your calendar.

Keep everyone informed. Nothing is worse for a project team than to be left in the dark. Morale will drop quickly if team members complete work, and then discover the project has shifted direction and their efforts were for naught. Missteps like this also waste project resources, lengthen timelines and increase costs. Make sure the communication processes you have in place keep everyone informed. It is better to copy people on e-mails that may not directly affect them than to leave them off these communications completely.

Set realistic expectations. Project success is often measured in three ways: on-time delivery, high quality and reasonable cost. A typical project will allow for two of these items to be achieved, so while it's important to reach for all three goals, good managers prioritize them. They know that if they want a project on time and at cost, the level of detail they can hope for may slip. Likewise, if they want high quality at a low cost, they may need to stretch timelines.

there is no spoon

[BroadbandBradley]

only users and hackers....tell the managers to read all the man files and create a powerpoint presentation to sum up open source, that ought to keep them busy for awhile.

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

[wrinkledshirt]

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

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

[dsplat]

Talk to the SourceForge people themselves about their efforts to sell support for the SourceForge software for internal corporate "open source" projects. The idea is that without imposing any particular license, the SourceForge platform provides companies with an "open source" development atmosphere. Source code gets shared, etc.

If you can get managers to understand that there is not one single thing called "open source software", but rather a range of licensing and development models that fit that name, you've solved half of your problem.

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.

Book

[joel.neely]

I'd like to recommend Open Source Development with CVS
as a good starting point.

What works for Apache

[vanguard]

While this isn't exactly what you asked for this is what works for Apache.

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

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 :-)

Regarding support...

[imrdkl]

A manager who uses open source software should know how to help his/her team get support. Showing them a working example of a bug being fixed from a user mailing list for some software product might be helpful. After they see it work once, they might be the first to browse the archives for help with a problem encountered by the team.

Just like any project management course.

[GISboy]

I'll admin I have second hand knowledge about project management, but I learned what I know from those that are/were very good at it.

Most people in a team/project enviornment fall into one of these catagories:
1) Coder; the one that can hack code like there is no tomorrow.
2) Cheerleader; the person that "cheers" everyone on and tries to motivate everyone.
3) Idea man; a person with a gift of "thinking outside" the problem. Usually very smart and somewhat competent as a coder/pseudocoder. Usually thinks of everything except the "how" to do something.
4) diplomat; Usually the project manager him/her self. The one that can "herd cats" or talk to the previous 3, iron out differences and balance all the powers of 1 thru 3.

The more you think about it, the more it is dead on. I've had the advantage, if you will, of observing several teams after learning this little tidbit. Once you see it, you can not un-see it.

The point is: You need all of these types, period.
As the PM you need to recognise these talents reguardless of working in person or via email/IM or whatever communications are your norm.

I give you Linus and Bill G. as prime examples.
They know how to motivate people by using their natural talents, they both know when to say "good job", "work on it some more" or (bill g, IIRC) "that is the stupidest fucking thing I've ever heard of".

As a PM you have the most challenging job, but have to realise that w/o the 3 types, the project is hobbled or dead.

Example of MS/FSF, again offers plenty of insight as to what goes right/wrong with development.

With MS, the divisions are political, social, and idealogical.
With Free Software, timezones/distance, language barriers and occasionally egos.

So, if a book is not around to help, go to a university nearby, and see these dynamics for yourself.

Never know, you might be the one to write the book yourself, with or without the help of a psychology and computer sci. phd.

Cheers,

GISboy

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.

I disagree

[FallLine]

While commenting code can be extremely valuable, it is often done as an afterthought. In other words, instead of abstracting, grouping, and naming (e.g., functions, variables, etc) the code properly at the get go, so that comments can be of significant value, comments are very often thrown on top in a manner that is of little help or, worse yet, is simply incorrect and confusing. Often times it's simply not possible to comment in a meaningful way until the code is properly designed. Ergo, I think most programmers are better advised to write clear code first and worry about the actual act of commenting second. My two cents.

Re:I disagree

[tim_maroney]

I think most programmers are better advised to write clear code first and worry about the actual act of commenting second.

Clear coding is very important, but clear coding only happens in the context of a clearly defined and well thought out code architecture. Such an architecture ought to come before anyone codes a line of anything except prototypes for feasibility investigations. A clear architectural document is more important for new programmers on a project than any amount of comments or of well-chosen class and member names.

Tim

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.

Re:I disagree

[tim_maroney]

In a polarized situation of the kind you describe, where the review process is dysfunctional, then yes, written plans may become a hindrance. The fault there lies with the review process, though, not with the idea of written architecture.

For user experience, an interactive prototype can often speak louder than a written specification. Again, it's too bad the review process was so dysfunctional that you had to sneak the prototype in, but in a well-functioning organization, creating a prototype build and showing it around to the stakeholders would be a valuable part of the user interface specification process.

Tim

Re:I disagree

[FallLine]

I agree with this, but, in my opinion, clear coding implies substantial architectural design wherever it is necessary (almost by definition). Whereas commenting, in and of itself, implies very little ( esp. given the number of worthless projects with worthless commenting).

I will make the point, however, that the projects that many, if not most, programmers work on do not great deal of formal up front design work. What's more, it's often outside of the scope of their job. Trying to over-design can be terribly unproductive.

Re:I disagree

[DGolden]

Are you implying some sort of idiot-ifying procedure between receiving the first degree and proceeding to graduate studies?

Well, the idiotification certainly exists. There's two main process I've encountered:

Aging, a genetically inherited disease that 100% of humanity currently suffers from. Aging of the brain has been experimentally determined to cause the inability to learn and decrease in intelligence

Alcohol abuse. In western society, undergraduates in many universities engage in "drinking games" and the like, which effectively amount to poisoning their own brains. A significant proportion of undergraduates do get noticeably stupider as "student life" takes its toll.

Re:I disagree

[sinster]

Yes, as an undergraduate. By that point, I had already been programming for 10 years (I started programming when I was 12, in assembly, on an Altos 5-5D "minicomputer").

There are two things that you apparently don't realize.

The first is that academia is overwhelmed by politics and jockeying for position. This is most prevalent among graduate students (who are struggling to attract influential professors as research sponsors) and among associate professors (whor are struggling to advance along the tenure track, which has progressively fewer openings the farther you travel). In academia, it's not the project that matters, but how you're able to leverage that project for personal advancement. Yes, the corporate world has politics as well, but aside from a few rare companies, corporate politics are babies struggling over teddybears in the crib compared to academic politics.

The other thing that you don't realize is that the nature of user interface design is that it is subtle. You need to come up with mechanisms that help the user out without the user being made aware that they're being helped out. That's the whole game. So if you come up with a successful mechanism, that mechanism is, by the very nature of the game, subtle.

Here are the details:

When I came on board, vertices were selected by clicking the mouse within 20 pixels of the vertice's location. When you have a lot of vertices on the screen, these regions overlap, and the specific vertex that gets selected when you click in an overlap is unpredictable (it depends on the ordering of the vertices in the data structures). You could even end up selecting a vertex that was scrolled out of the visible area of the layout.

My change was to define "pick regions". These regions were dynamic, depending on your view, the vertex density, etc. The way it worked was that I iterated over the visible vertexes (we had a data structure that made this easy, and also let us easily find the vertices closest to a particular x,y coordinate: that was another research project in itself). For any click location, I found the eight closest vertices. For each vertex, I calculated its weighted distance from the click location (I used distance-squared, rather than distance, for reasons that will become apparent). I found the vertex that had the smallest distance, and then I looked for the vertex with the second smallest distance. That second vertex's distance had to be at least 35% larger (that was a tunable parameter, and my experiments showed that 35% number to be the best) than the first vertex's distance in order for the first vertex to be selected. If that test failed, then no vertex was selected. All of these calculations were done using screen coordinates (pixels) rather than routing coordinates, so that the view parameters would get incorporated into the calculation. The net result of this is that each vertex was surrounded by a lumpy region that was "owned" by that vertex. Any click in that region would select the owning vertex. The regions were lumpy because their shape in any direction would depend on the neighboring vertices. But by using a distance-squared metric, the lumpiness was somewhat smoothed out, thereby avoiding long and counterintuitive peninsulae spreading through the layout (and spared me the cost of a square root calculation). The overshoot requirement ensured that there were gaps between every pick region, where a click wouldn't select any vertex. These gaps were about 16% of the vertex density (sqrt(1.35) ~= 1.16). So they were small enough that it would be hard to click in a gap, but large enough that any click that fell outside of a gap was unambiguously associated with the same vertex for both the computer and the user.

The change had two results: 1) when the user successfully selected a vertex, it was always the same vertex that the user intended, and 2) when the user was being ambiguous, no vertex would get selected. The second possibility also existed in the previous mechanism, so it wasn't noticeable. And the first possibility meant that the users never ended up selecting the wrong vertex.

So, yes, the change was subtle. It wasn't subtle to someone looking at the code, but at that time the UI was 5MB of dense X11 and Motif code, so the researchers never ventured into it. We also had a standing policy that no one was to touch anyone else's module, and if anyone needed UI work done, they were to come talk to me to code it. This all means that they never even looked into the code until after my bombshell was dropped.

I would talk about...

[kune]

1. Open Source Licensing
   • GPL and LGPL - differences
   • Other licenses
   • Allows project contract the use of Open Source (damages, warranties)?
2. assess maturity of software
   • life time of project
   • available documentation
   • existence of an active maintainer
3. organisizing in-house support
4. info sources & tools
   • Freshmeat
   • Google
   • sourceforge
   • Mailing Lists & mailing list archives
   • CVS
   • autoconf, make
   • lwn, slashdot, ...
5. active participation
   • How to send bug reports? (stay calm, don't flame)
   • contributing patches and improvements

Embracing Insanity: Open Source SW Development

[RC Pavlicek]

WARNING: Shameless plug follows...

I wrote the book "Embracing Insanity: Open Source Software Development" to educate management about the ways of Open Source. It deals less with project methodology and more with the social dynamics of the community, but you might find it helpful.

Here's a pointer to the Slashdot book review of it.

Project leadership.

[pete-classic]

I started a project that I call OSS-Leaders for OSS project leaders a few weeks ago. The idea is to create a place where OSS leaders can exchange ideas. It sounds like a simple idea, but when I was leading an OSS project and needed some advice from my peers I discovered that there really wasn't anything like this.

It is really just a (closed, moderated) mailing list right now, but I hope to distill some of the discussion into some sort of "OSS Leadership How-to" or something.

It is still in the preliminary stages, but we can't grow without members . . .

If you are the leader of an OSS project I hope you will check it out!

Feel free to mail me at my /. email if you have any questions or suggestions.

-Peter

PS: I use "OSS" above because the project is about the process (as opposed to the philosophy). Truth be known I tend to be a "Free Software Guy" but the project is intended to be agnostic about the OSS/Free Software debate.

AdAce's OSS work

[sinster]

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.

For dummies?

[Courageous]

Will Open Source for Managers and Open Source for Dummies be the same book?

:)

C//

The Cathedral and the Bazaar

[anshil]

"The Cathedral and the Bazaar" is one of the OpenSource bibles:
link:
http://www.tuxedo.org/~esr/writings/cathedral-ba za ar/cathedral-bazaar/


At least it was exactly this paper which has converted me some years ago...