Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Businesses Programming IT Technology

Collaboration Tools for Cross-Site Development? 12

Coordinator asks: "The company I work for has software development activities going in in several sites located around the world. We are looking for tools to help with cross-site collaboration. I am concerned about a one solution fits all approach, as well as something that requires too much time and effort to maintain on the part of our existing developers. A commercial product, or an open source product with a good support base would be very reasonable. What experiences have others had when trying to build a cross-site development environment either from scratch, or with existing tools or vendors. We are looking at some of the obvious places like sourceforge.net, gforge.org, and collab.net. Furthermore, we are looking at content management systems for knowledge base solutions such as TikiWiki or egroupware."
This discussion has been archived. No new comments can be posted.

Collaboration Tools for Cross-Site Development?

Comments Filter:
  • We use TikiWiki (Score:5, Informative)

    by Pengo ( 28814 ) on Wednesday July 07, 2004 @07:30PM (#9637241) Journal

    We have 2 main development offices, 1 in the US and one in Eastern Europe. We use TikiWiki for all of our document and information collaboration. we have tried various other solutions, but this seems to be the one that has sticked.

    Not only has our team been using it, but various other departments in the organization have started using it too. We all share the same server, but have setup various ACL and sections that allow us to easily keep people out of what they shouldn't be in.

    I have found that over 6 months of casual daily use, we have been able to create a HUGE amount of searchable and findable information. A lot of our operations procedures (ie. managing services, policies, etc) was created out of the documents that have been created and collected there.

    It's a snap to setup and very easy to maintain, I definately would say that I hadn't tried TikiWiki soon enough in our development process.

  • by cornice ( 9801 ) on Wednesday July 07, 2004 @07:39PM (#9637308)
    Furthermore, we are looking at content management systems for knowledge base solutions such as TikiWiki or egroupware.

    Zope [zope.org] and Plone [plone.org] require a bit of a shift in thinking but I would add them to your short list. Zope provides a rather robust framework and Plone provides a rather well tested CMF solution with plenty of add-ons available. Plus you get the benefit of an open source solution with corporate support [zope.com] if you need it. Note that I have no affiliation with Zope other than I'm a happy user.
  • recently I asked around for the best wiki... they all said tikiwiki.
  • This is an important question, and I am glad that you have asked it. I suggest, however, that you disabuse yourself of a few misconceptions first. You wrote:

    we are looking at content management systems [CMS's] for knowledge base solutions such as TikiWiki or egroupware.

    A CMS is not meant to help you manage knowledge, unless the CMS is hybrid software that is meant to be one-half CMS and one-half knowledge management system (KMS). I know a great deal about open source CMS's, and I do not know of any that are such hybrids. Furthermore, Wikis are generally not true CMS's, but, rather, one-half CMS and one-half "community-ware," software meant to faciliate the building of an on-line community. See my prior comment [slashdot.org] on the desirability of using such hybrid software.

    What is the purpose of a CMS? To make it possible for a non-technical user to build and maintain a web site by herself without the help of a web professional such as a web designer or web developer. The purpose of a true, non-hybrid CMS is to help you manage content, not knowledge. Content contains knowledge , of course, but groupware (see below) stores and re-uses that knowledge in a completely different way.

    As to knowledge management (KM), consider a prior Slashdot story [slashdot.org] and one of the best comments thereunder [slashdot.org], which derides the whole notion of KMS's.

    Note that some types of groupware (software that faciliates collaboration) include excellent KM, especially Lotus Notes. The KM in MS Exchange, the leading competitor to Notes, is much weaker.

    In summary, all too often, people confuse these types of web software applications: CMS, KMS, "community-ware," Document Management systems, and groupware. Furtheremore, hybrid software often fails because a hybrid often tries to do too much. A software designer maximizes his chances of producing good software by not trying to do too much and by aiming at attainable goals. In general, a designer should design his CMS to manage content, not also to facilitate the building of an on-line community or to facilitate collaboration.

  • by aminorex ( 141494 ) on Wednesday July 07, 2004 @09:14PM (#9637937) Homepage Journal
    And in that time, the tools haven't changed much.

    IRC for IM, CVS for revision/release control, and a website for shared knowledge. So back then it was manual RCS drops, and a gopher site, now I'm writing C++ and Java instead of Fortran and Lisp, subversion is about to replace CVS, and the website has become an application server. Mutatis mutandis, plus ça change, lalala.

    Really, the most advanced computer system that I ever used was a Symbolics Genera Lisp machine, ca. 1987. The best portable IDE I ever used was Wirth's Oberon-2 system ca. 1994. We still have mythical man-months, nobody uses functional languages with type inference for production, and we still use 32-bit address spaces with demand-paged virtual memory. Software is a frustratingly low-tech occupation. Personally, I think DOS and Windows are the principal culprits. I have seen the best minds of my generation sucked dry and wasted by segmented address spaces, BSODs, Visual blech and viruses.

    • I've got to half agree to some of this - rest, I'm just not that old, sorry ;). I was "let go" from major ISP and we did our cross site development work via IRC and a web based document center. We had upwards of 7 call centers and IRC on a central server seemed to work the best.
  • From the folks that brought you Slashdot, SourceForge.net, Freshmeat etc - all of the collaborative software development concepts employed by the Open Source development community are available in SourceForge for use within commercial software development organizations. SourceForge Enterprise Edition significantly extends on SF.net with a Role Based Access Control mechanism (RBAC), management dashboard, transparent integration with (*gasp*) MS Office tools and MS project. It has a wickedly broad API for int

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...