Software for a Virtual Office?

Omega1045 asks: "I am working on a team that will soon be merging with another group of developers a thousand miles away, plus we already have remote people. Having been in this position at a previous job, I have used applications like IM, NetMeeting, email and a lot of phone calls to keep people in touch. Even with these things, there is still a lot missing in making sure we have good communication between members of the team. In my previous experience, we spent too much time on simple tasks like making sure everyone had the same copy of a file, the same update project schedule, etc. What tools would you recommend for a team working in Windows development? What experiences, good and bad, have you had with 'virtual office' applications. I am currently testing Groove Virtual Office which I spotted on Slashdot, earlier. Does Slashdot have recommendations for free software, or moderately priced commercial software, that might fig the bill?"

Comments

GForge is good stuff

[tcopeland]

...some of the recent changes in CVS have some Microsoft Project integration, too. GForge is pretty good at handling reasonably heavy loads. And you can even get commercial support.

I'm not affiliated with GForge Group, although I was a committer on GForge for a while.

VPN routers, Wikis, and file servers

[treerex]

I spend a majority of my week working from my home office, driving the 50 miles each way into the company's building only a couple of days a week. I have a VPN router (LinkSys RV042) that extends the corporate network into my house. Our team uses a wiki for tracking issues and such, and shared file servers work fine: the approved or cannonical versions of software are put on the server and everyone is expected to stay up-to-date.

The previous reply to use rsync is a good idea if you want to automatically keep (force) everyone to the save versions of files and such.

We haven't used anything like GForge, though we do not have a lot of remote development going on (a few engineers cross country, the rest on the same coast.) Adding another email system (for example) on top of wahtever the corporate email system provides is a waste and senselessly duplicative. Similarly integrating our RCS into another larger system didn't make sense.

Subversion?

[RAMMS EIN]

``we spent too much time on simple tasks like making sure everyone had the same copy of a file, the same update project schedule, etc.''

That sounds like nothing a version control system couldn't take care of. I don't know about other systems, but I have good experiences with Subversion, and I am told there are Windows clients for it.

Re:Subversion?

[josepha48]

Yes, I'd agree. SourceSafe or CVS would help there.

Also centralized file repositories would help. A place where certain people could put files for others to read and get.

This really sounds like a poorly managed workplace.

Re:Subversion?

[Mr2cents]

If you want version control with cvs/svn under windows, I really recommend tortoisecvs/tortoisesvn. These handy clients integrate with the file manager, and are very user-friendly. It has been a while since I used it though.

http://www.tortoisecvs.org/
http://tortoisesvn.tigris.org/

Re:Subversion?

[Mr2cents]

In order to be sure you're convinced, I'll say it once more: you should give tortoisecvs a try.

I also use viewcvs to make the repository visible through a browser, but you're probably doing that too already.

http://viewcvs.sourceforge.net/

Wikis

[Knetzar]

I hate to use a tech buzzword, but wiki's (with offline copies) can be exactly what's needed. Building tables and documents directly in the wiki interface will make sure that everyone always has the latest copy.

Re:Wikis

[NickTopMoumoute]

I fully agree! Wiki's so simple to settle and use that it definitely worth a try. I've installed different flavors of Wiki (TWiki, Ouin Ouin, JspWiki, PHPWiki) 4 times and always with the same result: simply great! At the beginning you face the "oh no, not a new techno" pattern, but quickly developers realize they can share the same information and that it is always up-to-date. Here is an example of tasks my current Wiki is enabling:

• List of people, contacts
• Vocabulary used on the project
• Team's To Do List
• Team's Nice to have List
• Team's Ideas' Box
• Team's Tools List (with URLs)
• Presentation of arrays describing any kind of affectation/associations, who's doing what for instance
• ... and many other usefull information that needs to be share and also concurrently managed

Choosing a solution offering a Wiki plus many more tools to manage a project is certainly the best Way. I use a home made one but was told GForge was good. In addition to the shared knowledge base, people need to communicate. I recommand tools like Instant Messaging (Trillian) and emails (but try to define policies about emails use to avoid spams), but no phone! Calling someone by phone is perharps more enjoyable, but it implies a "both side lock" (both conterpart must be present at the same time) and no traces! To reinforce those tools, you can set a forum to ease discussions, debates and, of course, a good bug tracking system (I personally appreciate Mantis) to manage properly the bugs fix. No need to say that a versionning system has to be used! I'm still on CVS but plan to switch to Subversion.

Docushare

[Llama Keeper]

Xerox's Docushare product is like Sharepoint on Steroids.

Calendandering, versioning, chats & forumns, plus its a EDM (Electronic Document Manager), this coupled with e-mail, IM and a decent CVS, should keep you up to date.

Groove Office is supposed to be pretty good as well, but I haven't used it much, just Docushare. Plus I love Docushare because you can have a Linux(or better yet FreeBSD!) Front-End to a MS-SQL server.

be religiously cross-platform

[Anonymous Coward]

I work in a company of some 3000 people. The biggest issues we have with the "glue-ware" applications, which are used to keep everybody on the same page, come when the glue-ware requires a specific web browser to work, or is a binary that only works on one type of machine.

Now that the IT managers have got enough complaints, we are moving away from this. But the number of times I had to seek out a Windows machine, just to file a trip expense report, was not even funny.

More Info on Sharepoint

[c_dog]

My org has recently been experimenting with Sharepoint, and it works well for collaboration and document exchange. Much better than email, IM, etc. The software comes with several templates that let you manipulate the site into being useful for your intended purposes, and it is a free download from Microsoft.

There are only a few caveats that can potentially be a show-stoppers:

1. It requires Windows 2003 Server.
2. You must be willing and able to run IIS on the box. In fact, you really cannot use the IIS instance on the box where you install Sharepoint for any other web applications.
3. Although Microsoft SQL Desktop Engine is included with the Sharepoint installer, using MSDE is not too much fun when it comes time for Business Continuity Planning and Disaster Recovery (no management tools built-in to MSDE). Ideally, a Microsoft SQL Standard Server (locally or on another enterprise maching already filling this role) should be used if you are not comfortable using T-SQL to script MSDE backups.

I've seen other F/OSS solutions out there that run on Apache with PHP or Zope and use MySQL as a DB back-end, but if you're Windows-centric, the Sharepoint install was quick, easy, and did not require much forethought aside from the issues mentioned above. Wouldn't be my first choice for dev collaboration for non-Windows-centric orgs, but sounds like a decent choice for your situation (based on what you told us).

Good luck!

Make time to actually meet the "other" dev team

[Curmudgeonlyoldbloke]

There are plenty of good technical solutions to source code control, messaging, mail, etc. (lots of which are posted already) that allow you to work together, but to actually work together effectively yet remotely you need to get to know the people who you are working with - and this means meeting face to face semi-regularly.

If you don't do this, then you'll always be two development teams - "us" and "them".