Sohodojo and Communities of the Future proudly host...
The Center for Community Collaboration Technologies
Specification Writing for Web-based Project Planning Software
Phase 1: Post Mortem and Lessons Learned

[ SourceXchange Project #24 Accomplishments Introduction ] [ Collab.Net/SourceXchange Project #24 Accomplishments ] [ My (Jim Salmons) Accomplishments ] [ Collab.Net/SourceXchange's Accomplishments ] [ Opendesk's Accomplishments ] [ SourceXchange Project #24 Lessons Learned ] [ In Conclusion ]

What Went Wrong at Collab.Net's SourceXchange?

Hello Anyone interested in SourceXchange Project #24,

First, to those interested in this project, please understand that the project on behalf of the Open Source Software Developer Community known as "Spec Writing for Web-based Project Planning Software" is alive and well, hosted at the Center for Community Collaboration Technologies:

http://sohodojo.com/techsig/project-planning-project.html

This means that the quality work-to-date on this project will remain on-line as an Open Source Software Developer Community resource despite the fate of this project's current funding as originally established under the Wish List Program at SourceXchange.

Our project sponsors have withdrawn their financial support for the completion of the project. The core team members, Jim Salmons and Frank Castellucci, intend to complete their work on behalf of the Open Source Software Developer Community by finding alternative funding sources for this much-needed Open Source Software Developer Community project.

So, bottom-lining it: project, alive and well; original funding, gone; next steps, new funding as we keep our 'eye on the prize'.

In the remainder of this post-mortem note, I will address our project's accomplishments and lessons learned under this first phase in its lifecycle.

The accomplishments of SourceXchange Project #24 can be considered from at least five perspectives:

• The project itself
• Me, Jim Salmons, an Open Source Software Developer
• Frank Castellucci, an Open Source Software Developer
• Collab.Net's SourceXchange
• Opendesk

By far, the most significant accomplishments are those of the project itself. And even though I would be considered an 'old dog' by most standards, I learned some new tricks that qualify as personal accomplishments. And although I cannot speak officially on their behalf, both SourceXchange and Opendesk had accomplishments despite their decision to stop funding our project.

See Frank's 'Open note to mailing list participants' note of 10/30 for his Lessons Learned perspective on this project.

Note: Unfortunately, you cannot read Frank's post because SourceXchange has deliberately destroyed our project's mailing list archive and has refused our requests for restoration or a copy for hosting on this web site.

1. While there were MANY Open Source projects, past and present, which have contributed technologies to the 'project planning' and 'project management' domain, SourceXchange Project #24 effectively put Open Source Software 'on the map' in terms of search engine and directory visibility for our community.

   A trip to Google, Yahoo!, Northern Light or other search engine to perform queries on such terms as 'project planning', 'Open Source collaboration', 'collaboration technologies', 'project management', etc. will return NUMEROUS results pointing to the SourceXchange Project #24 project website! Many of these results are in the 'top 5' or 'top 10' query results... some are Numero Uno!

   In October, over 92% of the unique visitors to the SourceXchange Project #24 project website CAME DIRECTLY to the site from sources OTHER than SourceXchange. This is a testimony to our effectiveness in establishing a 'beachhead' for this project as an Open Source Software Developer Community resource as well as informing the general public of the interest and contributions of the Open Source Developer Community to the project planning and project management solution domains.

   All stakeholders in this project recognized that this project was the first in an evolution of related projects which would be needed to bring the specification's requirements to life under a variety of designs using various Open Source technologies. By creating The Center for Community Collaboration Technologies and this project's own web site, we have successfully created a 'destination and repository' for this important collection of Community-based projects.

   As a small business webpreneur, I appreciate how difficult it can be to establish this level of persistent, visible presence in today's Web Cacophony. That's why I list our establishing our project's web presence first in our list of accomplishments. We have effectively set up the context for this project to meet its objective through an evolutionary series of community projects. This is a legacy contribution to the Open Source Software Developer Community regardless of the fate of this project at SourceXchange.

2. Frank and Jim COMPLETED three high-quality milestones within the original five-milestone plan, contributing substantive content and knowledge in the problem domain on behalf of the Open Source Software Developer Community, the intended beneficiaries of this Wish List project.

   The 'Comparables Analysis' (M2) is a particularly noteworthy accomplishment as it comparatively details the features of nine popular project planning and project management application- and web-based service offerings. Milestone 3, an early draft of the final SRS including a list of functions to be included in the final spec, is also noteworthy as it identifies the four areas where the 'big wins' are in terms of designing Open Source project planning technologies which address the UNIQUE NEEDS of the Open Source Software Developer Community.

   These quality deliverables are permanently and publicly available at our project's website which remains an Open Source Software Developer Community resource despite our current loss of funding to complete the project at this time.

   As an indication of the interest in and accessibility of this information, this project's home page is now the SECOND most popular entry point to Sohodojo, the host of our project.

3. As stated in our original proposal, this project has 'spawned' the Center for Community Collaboration Technologies!

   This Open Source Software Developer Community resource, as described in our original winning proposal for this project, is now a highly-visible and growing destination for Open Source Software developers interested in collaboration technologies.

   In an exciting recent development, The Center for Community Collaboration Technologies has become a node in the Communities of the Future Network! The CCCT will serve as an 'Applied R&D Lab' of the network, contributing the design and development of a server-based Open Source collaboration platform for COTF's international collection of Community Centers, Futures Institutes and their various projects. This is a significant accomplishment that would not have been possible without the work enabled by this project.

1. I took an 'Embrace your enemies' approach to developing the Core Team for this project... and it worked GREAT! In my 'former life' in corporate consulting, I would NEVER have recommended that I team with the person who was the most vocal detractor/nay-sayer of my ideas and proposals during the RFP process. You need only look to the RFP comments to see how Frank and I had at each other verbally prior to joining forces on this project.

   I would never have done this in my corporate life because it would have been too risky. But since this was a Wish List project for the 'greater good' of the Open Source Software Developer Community, I felt it was important to have a balanced perspective representative of the broader community contributing to this project's Core Team.

   The great thing is that this worked out well beyond my expectations. After his initial shock that I would have recommended him for the team, Frank and I had no trouble establishing a collaborative, effective working relationship. Indeed, although our experience, perspectives and interests are very different, we have established a trusted, respectful working relationship that will last beyond this project.

2. I refined and extended by abilities to create, maintain and, most notably, PROMOTE an Open Source project web site. There are some clever techniques I applied to the development of the project web site which have made it MUCH more effective in reaching its intended audiences.

   I am excited to see that a search on 'project planning' at Google will return our project's web site in the 'top five' results! And I am excited to see that I have turned this project's home page into the second most active entry point to Sohodojo.

   These are techniques and insights that I will take with me to ANY Open Source Software project in which I get involved. It is unfortunate that SourceXchange does not seem interested in mining our project's experience to help other Collab.Net/SourceXchange projects achieve similar successes with their project web sites.

1. Although beset by Sponsor commitment problems, this project successfully kicked off the SourceXchange Wish List program.

2. This project was a SUCCESSFUL DEMONSTRATION of a Collab.Net/SourceXchange project with MORE THAN ONE developer. Indeed, we were more than a two-person team, we were CO-LEADS with EQUAL responsibility and authority in managing this project! Ironically, despite this 'leaderless' (all-leaders) collegial composition, the Core Team ALWAYS kept to its work-effort milestone time-boxes. It was the Sponsors' lack of participation that delayed this project, not the team's management model.

3. Due directly to this project's 'squeaky wheel', Collab.Net's SourceXchange mail list archive feature is now capable of handling more than 100 messages!

4. Although ignored by the Collab.Net/SourceXchange sponsor contact, this project contributed a significant number of 'experience reports' and substantive proposals identifying problems in, and possible solutions to, Collab.Net/SourceXchange's project contract business process. Although these contributions have been ignored, they are an accomplishment that SourceXchange should be pleased about and should mine for improvements in its core business processes.

5. As sponsors of this project, SourceXchange helped to kick off The Center for Community Collaboration Technologies.

1. As sponsors of this project, Opendesk helped to kick off The Center for Community Collaboration Technologies.

Among the insights learned or re-learned on this project are the following:

1. Don't let a project start without consensus on a FINAL and COMPLETE specification of the deliverable work product.

   While Frank and I can both be faulted for 'cringing but not screaming' when this project kicked-off prematurely, the problem can largely be attributed to poor design of SourceXchange's web-based business process for managing projects. We were in the midst of floating a proposal revision for this project when the project was 'turned on' under the Collab.Net/SourceXchange web-based process and we started rolling.

   At the time, we were all basking in the reveries of "We love you, you love us. We're all in this together. Go, team, go!" So we didn't take this premature start as seriously as we should have.

   There is NO DOUBT in my mind that SourceXchange should improve its project 'kick-off' decision-point to be an 'n-way' consensus decision requiring ALL agreeing parties to 'press the Go button'. I have doubts that a one-way contract acceptance is even binding since we developers were not included in the contract acceptance decision.

2. SourceXchange needs a dispute resolution process to address problems with sponsors in addition to its current procedures for handling disputes related to the work performed by developers.

   The current Collab.Net/SourceXchange business process, as embodied by the Peer Reviewer role, assumes that disputes will be about the work performed or about the developer's competence or availability to perform the work of the project. There is NOTHING in Collab.Net's SourceXchange business process to deal with misbehaving, disruptive or ineffective Sponsors.

   Note that even in the 'Customer' context discussed in the next lesson-point, such a dispute resolution process is needed in the case of the Sponsor's delegate performing poorly in the web-based Collab.Net/SourceXchange Sponsor role. In these cases, there needs to be a 'red flag raising' mechanism whereby other stakeholders in a Collab.Net/SourceXchange project have a means to effectively communicate with Sponsor contacts in a position to assess and correct problems with delegates assigned Sponsor roles on behalf of Sponsor organizations.

3. 'Sponsors' is a MISLEADING role name in the Collab.Net's SourceXchange business model.

   Following the 'Call a spade a spade' bit of common sense, Collab.Net's SourceXchange 'Sponsors' should be called 'Customers' because THAT IS WHAT THEY ARE. The word 'sponsor' is used to describe a mutually-beneficial relationship which DOES NOT grant authority of the Sponsor over the activities of the entity 'sponsored'. McDonald's does not get to tell the Olympic Committee to use 'Big Macs' in place of the traditional discus in its track and field event.

   Sponsors 'sponsor', they don't oversee and manage. While 'Sponsor' sounds all hip and happening in the context of 'Gen-D' and Open Source, the use of this term undermines the effectiveness of Collab.Net's SourceXchange contract-project business process.

   By using the term 'Sponsor', Collab.Net's SourceXchange unwittingly signals to its service customers that a Collab.Net/SourceXchange project is less demanding on its customers than traditional development projects. The implication is that less time, energy and participation is required than with a conventional project. The implication is that 'you are still in control', but you don't have to work as hard, as quickly or care as much as you would normally in a 'customer/client' of development services relationship.

   With over 25 years of software development experience, I have NEVER seen a significantly successful development project that did not involve the dedicated and involved commitment of the Customer in active collaboration with its development team partner throughout the development lifecycle. SourceXchange is asking for recurring, frustrating problems in its projects as long as this confusion about the true nature of the Sponsor role exists.

   (See our project's mail list archive for postings related to this significant problem, including an ignored suggestion to consider adding a 'Surrogate Customer' role to Collab.Net's SourceXchange business process as a complement to the 'Peer Reviewer' role. Note: SourceXchange has destroyed our project mailing list archive and refuses to provide us a copy. We regret the inconvenience.)

4. While funders of 'regular' Collab.Net/SourceXchange projects should be able to select between Customer and Sponsor roles, Wish List Program projects should have only Sponsor funders AND competitively-selected, paid Surrogate Customer roles to proxy on behalf of the Open Source Software Developer Community which is the intended beneficiary of Wish List projects.

   I don't see ANY way that the SourceXchange Wish List Program can achieve its intended potential without breaking the 'Sponsor-in-charge' authority model embedded in the current Collab.Net/SourceXchange project-contract business process.

5. The SourceXchange web site is relatively ineffective in showcasing its developers and their projects and in generating traffic to our project web sites.

   I had expected that having this Wish List project linked from SourceXchange to our project home page hosted at Sohodojo would be a big 'intangible compensation' to consider against the low budget for the work required. As it turns out, only about 8% of our project's web site traffic last month came directly from SourceXchange. Indeed, small community-based Open Source sites like Advogato routinely generated 10 to 20 times more referrals to our project than Collab.Net/SourceXchange's web site did.

   As an Active Developer I would have to say that being an Active Developer seems like a 'dubious achievement' if you take your impression from the current SourceXchange website. Under the 'Community' category of the page navigation bar there are four items; Sponsors, Developers, Peer Reviewers and Events. Sponsors and Peer Reviewers are given individual showcase profile pages. Even Events are worthy of individual profiles. But we Developers are nothing more than a tote-count and list showing our skill distribution over 'the herd of chattel' for sale in CollabNet's SourceXchange marketplace.

   Lucky Brian Goetz of Quiotix Corp., however. As the first and only profile in the Developer Spotlight 'series', Brian has enjoyed a disproportionate benefit of being an Active Developer. The article featuring him has been a Collab.Net/SourceXchange home-page featured link SINCE THIS 'SERIES' ARTICLE WENT UP IN JULY!?

   Hello, SourceXchange... I am an experienced, competent, free agent, self-employed Open Source Developer trying to be a member of your Active Developer community. I am not a number. I am not nameless chattel to be hawked to your corporate clients like a piece of raw meat. Folks like me and Frank are working hard to make our projects productive, interesting and beneficial to the Community. Tell our stories, too. Be as interested in collaborating with us as you are in cutting your next deal with a 'Valley player'.

   Developing and enhancing the effectiveness of SourceXchange's community of Open Source developers, folks like Frank and me, should be your most dear CORE COMPETENCE. Take a look at your current web site through the eyes of the Active Developer. What does it say about how SourceXchange thinks about the Open Source Software Developer community? It tells you a tale that is consistent with the decision to cancel a Wish List project because we refused to allow our agenda to be driven by inexperienced and self-serving sponsors who forgot about what a Wish List project is all about.

   I truly hope that our bad experience will lead SourceXchange to consider changes to its web site and business processes that will clarify and reinvigorate the Wish List Program in the spirit that it was created.

I hope that SourceXchange Project #24 gets a reprieve and rebirth. Frank and I have developed an effective working relationship. The project goals are of vital interest and importance to the Open Source Software Developer Community.

Regardless of our project's fate at SourceXchange, 'Spec Writing for Web-based Project Planning Software' is alive and well at the Center for Community Collaboration Technologies. We'll find alternative funding, perhaps even reviving the project at SourceXchange. Time will tell.

In the meantime, SourceXchange, I hope somebody there takes the time to read and think about this contribution to our project's post mortem.

This Open Source project is not going away. We're only recouping and regrouping from a rocky but productive start.

Thanks, Frank, for being a great team mate!

Respectfully submitted,
--Jim Salmons--
SourceXchange Active Developer and
Co-Host and TechSIG Leader
Sohodojo
http://sohodojo.com

© 1998-2010 Jim Salmons and Timlynn Babitsky for Sohodojo excepting project web pages and documents which are published under the appropriate Open Source documentation license.
Our Privacy Statement
"War College" of the Small Is Good Business Revolution
Website design and hosting by Sohodojo Business Services,
A Portfolio Life nanocorp

[ Support Sohodojo ] [ Translate page ]
[ Search site ]