Differences between gotdotnet CodeGallery and Workspaces

When I joined the gotdotnet team with Betsy and our illustrious leader, Sandy back in February/March, we quickly determined that improving the reliability and performance of GDN Workspaces should be our #1 goal. To that end, we initiated two projects:

  1. Project One focused on pinpointing and correcting the sources of our performance and availability issues, primarily in Workspaces. This project is almost complete and judging by the limited number of customer complaints that I've seen over the last few months, we have achieved our goals. The hardworking gotdotnet development team has improved GDN uptime from the high 80's to the upper 90's in just a few short months.

    Workspaces is a great solution for collaborative development projects where the members of a team utilize different offline bug tracking and/or source control software, do not have their own source control or bug tracking software for offline use, or in cases where members cannot otherwise access a central source control database and/or bug tracking repository. Source control and bug tracking are essential tools in the collaborative developer's toolkit but to use them effectively, all project members must use the same ones. Workspaces enable geographically dispersed and "naturally formed" teams to standardize on one source control system and one bug tracking system, thus enabling them to concentrate on what they do best: write great code!

  2. Project CodeGallery focused on gathering user feedback, rationalizing our use cases, and providing an alternative to Workspaces for users who don't necessarily need all of the premium features and functionality that Workspaces provide to capitalize on the benefits of collaborative development online. We determined that most gotdotnet users and teams want to share their code and/or binaries but they don't all need source control. Consequently, we created a new site component called CodeGallery, which is essentially Workspaces minus source control.

    CodeGallery is ideal for the development of code and other intellectual property for individuals and teams who want to tap the community store for design ideas and constructive feedback without granting project members the ability to modify source files. CodeGallery embraces the 'code in private - share and discuss in public' development model, also known as "feedback-driven development".

From a performance perspective, versioning is expensive. Since we don't do any versioning on the back end for CodeGallery project items, performance is much better. Again however, we have made great strides in improving the performance of Workspaces relative to a few short months ago.

Get the Point, Korby. What's the Delta between CodeGallery and Workspaces?
Workspaces provides source control (aka version control) for developers who are actively developing components and applications with other team members, online and in the open. In a workspace project, team members can check out or get the latest version of project files, code, run and debug, and build offline, and then check in their changes. All past versions of source files are stored in the source control database and can be gotten at any time. Team members can also log bugs, generate activity reports, and have discussions.

In a CodeGallery project, project members can download the latest version of a project's files but they cannot retrieve past versions (unless the project admin explicitly saves them using a different name) because we don't store them. However, project members can log bugs and have discussions in the context of a CodeGallery project in the same way they can in a Workspace project.

Other Differences between CodeGallery and Workspaces
Except for source control, CodeGallery projects offer all of the features and functionality of Workspaces projects. In addition, CodeGallery introduces the following features and feature improvements:

  • Users can create multiple Message Boards per project.
  • Searchable Message Boards 
  • Search keywords are highlighted in yellow
  • Project activity is calculated on a bi-weekly basis.
  • Bug Tracker system is zippier than in Workspaces.
  • More extensive Alerts Console
  • Auto-admit project membership requests
  • Invite others to join
  • Users can upload HTML files that can be read by clicking on a hyperlink
  • Users can customize a project home page to a much greater degree
  • Reports display the following information for a CodeGallery project:
    • Most Active Members  -  List of members with more posts grouped by message board.
    • Unanswered Posts  -  Threads with unanswered posts by message board.
    • Project Activity  -  List of the Project activity in terms of page views.
    • Reasons Members Have Given for Joining This Project – can provide some interesting feedback regarding your user base.
  • Custom UR Ls can be added to point to related sites, or sites that can help your project in some way. These links can be logically grouped.

What's Next for gotdotnet?
As I've said in the context of past projects I've worked on at Microsoft, my name is Korby Parnell and I love to share what I'm working on or passionate about (usually the same thing) with anyone who will listen. It's a personality disorder that inspires me to be a decent blogger and a great product planner/manager of social and collaborative development software. Despite my urge to tell you everything that we have planned for gotdotnet, it would be unwise of me and disrespectful of your time for me to over-promise something that I'm not 100% certain we will deliver. [commence tongue-biting]

What I can say is that in the coming weeks and months, gotdotnet.com will continue to improve before your very eyes and you won't be disappointed. Pull out your hymn books and sing along 'cause the Great gotdotnet Revival has just begun. For more dirt than that, get yourself invited to the next gotdotnet CodeSlam (tentatively scheduled for mid-December at the p&p Summit in Redmond) or subscribe to my blog and try to read between the lines.