Ask HN: What Can Distributed Software Development Teams Learn from FLOSS?
2 comments
There was a previous discussion about fully distributed teams here: https://news.ycombinator.com/item?id=3976819
It sounds as though you're doing a partially distributed team though, which is hard to do correctly. You basically have to treat the remote workers same as a remotely-managed multi-site team, except a site has only 1 worker. You have to worry about any resulting politics and the remote worker(s) getting marginalized and upper management thinking "If they're not present they must not be important to the payroll". That decision made informally during free bagel friday? They haven't heard about it.
One way I've heard it put is that everyone in the office now works in a corporate branded internet cafe, and should assume they're working fully remotely. That means more written artifacts about decisions and design.
From my own experiences, similar timezones work best. If you're in the US and your coworkers 12-13 hour different from you, it's going to be difficult if you're the only person holding everything together without some working hour modifications from either side.
For the technical issues, you need a realtime and asynchronous communication component. Chat and email works fine for this, though you can also do an audio/video chat.
It sounds as though you're doing a partially distributed team though, which is hard to do correctly. You basically have to treat the remote workers same as a remotely-managed multi-site team, except a site has only 1 worker. You have to worry about any resulting politics and the remote worker(s) getting marginalized and upper management thinking "If they're not present they must not be important to the payroll". That decision made informally during free bagel friday? They haven't heard about it.
One way I've heard it put is that everyone in the office now works in a corporate branded internet cafe, and should assume they're working fully remotely. That means more written artifacts about decisions and design.
From my own experiences, similar timezones work best. If you're in the US and your coworkers 12-13 hour different from you, it's going to be difficult if you're the only person holding everything together without some working hour modifications from either side.
For the technical issues, you need a realtime and asynchronous communication component. Chat and email works fine for this, though you can also do an audio/video chat.
Perceived FLOSS success rate may be due to selection bias
On the other hand many FLOSS projects do not seem to suffer from the same problems (especially premature deaths), 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 in a company more often?
I'm interested in the opinion of others especially regarding technical issues like source code ownership and revision control system, but also ways of communication, dealing with cultural differences, ...