Project Collaboration Tools [closed]

Question

I formed a startup business six months ago. The first product has been designed consisting of a PCB, some firmware, verification tests, and some supporting PC-based application software. The first prototype is ready for commercialism. Therefore I am looking to add a team to help bring this to market and to further build this venture.

To do this I am looking for ways to collaborate with these new team members, some of which are located all around the country in different time zones. The team will be expanding from just embedded design to include: mechanical designs for enclosures, website design, and business and marketing development. I have looked at a dozen or so web-based tools. Many charge a monthly or annual fee and start you off with a crippled free starter site.

I am not looking for recommendations here in this post. These are easy to find via Google. What I am looking for is useful comments from engineers who have used collaboration tools in the past. I'm looking for something more extensive than just GitHub. This startup is based on embedded products so comments from working hardware and software engineers are very important.

1. What features did you like?
2. Did the team welcome it's use, or did interest wane as the project moved on?
3. What features were missing and you wish were included?
4. Which features were too complicated or could be simplified?
5. How were files shared and stored? Or did you just use something like Dropbox?
6. What would you use in your next project?

I welcome any comments on your experiences with collaboration tools? Maybe this post will start a dialog useful to other embedded engineers. Thanks to readers of this posting.

Answer 1

I wouldn't go with somebody's web based anything. Do you really want to trust the life of your company to some random schlubs running a web site?

I'd set up the tools I like inside my company's network, with no outward facing services at all. Then, all of the folks working remote get a VPN login that gets them inside of my network where they can use my tools.

1. Share source code through a versioning system. Git would probably work best given the distributed nature of your setup. There's a special little spot in hell (where the fire burns hotter and the demons are meaner) reserved for people who try to do software development by sharing files without a versioning system. The devil personally handles those who use dropbox instead of a versioning system.

2. Use a good system for planning your tasks. We use Jira, and it works well enough.

3. Find a good project management program to keep track of requirements and progress. Let me know if you find one. We don't have one where I work, and we've never found one.

4. You need a system to track support calls. We have one that we use, and it is sort of OK. Can't recommend it because it is a German product and is only available in German. It isn't really all that whoopy anyway.

5. Use a chat system internally. When one developer or engineer needs to ask another about technical stuff, a chat works better than email.

6. I use Github for some of my personal projects, and that works well enough - for the small stuff I do at home. I wouldn't want to use it at work. It just doesn't have what it takes to handle what we work with. We had around a thousand support calls and finished like 2000 tasks over the last year. From my personal experiences with Github, that would have been no fun at all.

7. Integrated solutions are great, until you run up against some limitation that you can't live with - but then you can't get out if it because all of your data and history are in some propietary system and you can't get out of it. Having a bunch a independant systems is a pain, but your data is in your hands and you can move it to a new system if you must - or bite the bullet and, for example, replace your chat system and just take the loss of the history (but only for the chat rather than everything you had tied up in the integrated system.)

---

That's my take on the subject. I expect this question to be closed shortly as too broad or too opinion based. Opinions are about all you can get in answer to the questions you've asked.