Ask Slashdot: What Can Distributed Software Development Teams Learn From FLOSS?

An anonymous reader writes: As a long time free software proponent and leader of a small development team (10+ people) within a mid-sized company, I always try to incorporate my experiences from both worlds. Lately I was confronted with the need to accept new team members from abroad working on the same codebase and I expect to have even more telecommuting people on my team in the future (even though research suggests the failure rate of virtual teams could be as high as 70%). On the other hand, FLOSS does not seem to suffer from that problem, despite being developed in a distributed manner more often than not. What can corporations and managers learn from FLOSS to make their distributed teams more successful? Consequently, what FLOSS tools, methods, rules, and policies can and should be incorporated into the software development process within a company more often? I'm interested in hearing what you think, especially regarding technical issues like source code ownership and revision control systems, but also ways of communication, dealing with cultural differences, etc.

Comments

You Can't Fix It

[Anonymous Coward]

FLOSS can simply reject code that's not up to standard. If someone on your team turns in shitty code you can't always just not use it.

Re:You Can't Fix It

[ranton]

Unless you can get management to sign on to a mentality of "it will be done when it's right" rather than "it will be done on Thursday"

A mentality of "it will be done when it's right" is almost as foolish as "it will be done on Thursday." Software will never be "right". Quality software requires people who are able to perform proper risk management during all stages of development. I will not prevent my team from moving from discovery to design just because I think there may be requirements we are missing (hint: there always will be). We will move on when I believe the risks of moving on are less than the risks of not moving on.

My current backlog is full of feature requests, suggestions for more clear UIs, bug fix requests, etc. If I waited for my backlog to be clear before each release, my boss would still be waiting for our alpha version. Part of my job is also making business users comfortable with my change management decisions. If my bosses implore me to finish testing too early or slack on documentation, it is largely my fault for not convincing them it is a bad idea.

Re:Skype is for children.

[Anonymous Coward]

I use IRC and chat pretty extensively at work, but some conversations just work better over voice.

Not everything's a nail. Just sayin'.

FLOSS has the same issues

[bloodhawk]

Who told you FLOSS doesn't have those problems? they lied. many FLOSS projects fall apart because of the "virtual teams" of people with different goals and aspirations. I would not be surprised if the failure rate is even higher than 70%

What can on-location software teams learn from OSS

[phantomfive]

Here's what a lot of teams need to learn:

A lot of meetings can be done more efficiently and effectively by email. Here are ways you can tell:

1) If half the people in the meeting are checking devices, not listening, the meeting should have been done by email.
2) If everyone sits down at the 'stand up' most of that meeting should have been done by email.
3) If people are standing around with blank looks on their face, the meeting is probably a waste.
4) If the meeting is in the morning, and after lunch no one can remember what happened, the meeting is a waste.
5) If the meeting ends exactly one hour after it starts, then it's a time filler. Finish the meeting when everything is accomplished, not when the time is up.
6) If it's not clear what needs to be accomplished in the meeting, it's a waste of a meeting and should be cancelled.

Someone above suggested that the meeting could be done over IRC instead of email. That is also a perfectly acceptable alternative.

Yup, exactly

[Giant Electronic Bra]

All you probably NOTICE are the more successful FLOSS projects. For each one of those, there are 100, possibly even 1000 that languish, maybe make a release or two, and then lie in their shallow graves on sourceforge for the next 10 years.