Slashdot Mirror
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.
I think a big difference is in how you can just 'fire' people casually in FLOSS. You don't have to accept people's pull request. You can tell them their code sucks, w/o sugar coating it. There's also non-monetary incentives that drives FLOSS that you'll have a hard time duplicating. That said, may be make it clear to your boss that you should be given the power to reject bad code w/o lengthy explanation. The ability to change team members easily if need be. Also, may be the ability to say more about a project when posting job positions, and not just the generic, "Over x years of experience in y". The linux kernel is a good example. Also, you must have people who knows git well.
Gimme a break. One talking head wants to publish a "study" and suddenly it's canon? What does "failure" of a virtual team even mean? Probably, less money for the talking head.
Virtual-enabled teams, in my own experience, may not result in any massive, curve-jumping gains suitable for a click-baity headline, but I do think they are at least as good, and decisively better in a few key ways, as traditional, rigidly office-bound teams. They are cheaper facilities-wise, and result in vastly higher morale and loyalty among the employees who are able to work from home. They do not result in goofing off or falloff of productivity, except among employees who were worthless anyway.
Ultimately, virtual-enabled teams amplify whatever is good or bad about the leadership and quality of the hires. Good hires become great hires because they don't waste their work house stuck in ever-increasing traffic. Do-nothing managers become disaster managers. And the morons who represent the failure of the hiring process will spend their days at the beach and be discovered far earlier than they would have.
Virtualization is a Great Thing. But it highlights how the current state of management and hiring in software is a Terrible Thing. Don't believe the haters.
Very much so. Most FLOSS projects fail or are not very good. The other thing is that successful FLOSS projects often have very small teams of very good and dedicated people. Often you find that things are handled by just one person that really, really knows what they are doing.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.