Zacker.org

At the Yearly Kos convention on June 8th the CivicSpace community will be teaching a workshop on building netroots campaign websites. Experts will be avaliable all day to teach participants at every skill level. The day will culminate in a barn raising of a real world netroots campaign website thought up by the DailyKos community and built by workshop participants and facilitators.

This thread:

http://www.dailykos.com/story/2006/6/6/13713/38510

is being used used as a campaign idea incubator with the best concept being built three days from now at the YearlyKos convention. If any of you are DailyKos members we could use your help recommending the thread so that it gets exposure within the DailyKos community, also please submit your ideas if you have them. If any of you want to help out please send me an email and let me know:

1. If you will be attending YearlyKos
2. If you want to help facilitate the workshop
3. What specifically (if anything) you would like to pitch in on.

Hope to I'll see some of you in Las Vegas shortly.

Spencer Critchley recently interviewed me about CivicSpace, Drupal, and DeanSpace for the O'Reilly OnLamp blog.

I've had the pleasure of working closely with David over the past year on CivicSpace/CiviCRM and the People Finder project. He has been working in the social technology sector towards a vision quite similiar to the CivicSpace project for ten years (since I was in middle school). He is passionate, articulate, and usually knows more than me. As the managing partner of CivicSpace LLC responsible for strategy and business operations he will be a very important addition to Kieran's team working on getting CivicSpace on-demand off the ground. Here we go!

Jeff Robbins of Lullabot posted a podcast interview of me here. I babble on for an hour or so about the Dean Campaign, DeanSpace, and CivicSpace.

I've poured almost three of my life in to CivicSpace waving my hands and willing it into existance. We have a lot to show for it: 30 major software releases, two thousands CivicSpace powered websites, a vibrant and quickly growing user community, and a network of 25+ vendors occupying a solid slice of the marketplace of advocacy / non-profit web technology services. But what we haven't had so far is a solid user facing product - something I can show my mom...

Ten minutes ago I sent a note to our mailinglists announcing that we will shortly begin alpha testing a hosted CivicSpace service and are looking for testers. Three minutes later four people signed up.

The CivicSpace hosted service is almost here and I couldn't be more excited.

John Stahl recently gave me some heat for my assertion that Elgg should be built on top of Drupal.

I think that the next few years are going to bring tremendous challenges for applications that do not easily communicate with other applications that are “outside their platform” i.e are written using a different language/framework, run on a different server, etc....The days of monolithic application stacks that try to do everything are fading fast. A new “network-centric” software ecosystem is starting to bloom.

This is wishful thinking. I've spent much of the past few years puzzling over this exact question. While I am personally very much a proponent of web standards and web services I am pessimistic as to how much immediate impact they will have in the evolving marketplace of non-profit/ngo & advocay web technology services.

Backstory

I didn't always think this way. If you told me a year and a half ago that I would be hawking CivicSpace/Drupal as the über-platform that could meet virtually every need of any size organization I would have told you you were nuts....

After the Dean campaign ended and we started work on CivicSpace our assumptions were:

• Drupal wouldn't be able to "scale" to meet the needs of large organizations
• We would not be able to develop the platform quick enough to meet all the core needs of organizations any time soon
• We would integrate third party service providers to fill the functionality gap organizations required

Then some interesting and unexpected things happened:

• It turned out Drupal could scale
• CiviCRM showed up and filled the functionality gap
• Lots of vendors established quickly growing businesses servicing the technology. The top half dozen firms now employ ~ 50 people between them and each are looking to hire.

This reshaped my thinking on the future of the web-technology marketplace quite a bit. We have an immediate opportunity to commodify the core web-technology organizations need to a single integrated and scalable open-source application stack and this is a very good thing for the marketplace. Over the next few years I believe the advantages afforded by this stack of technology (CS/Drupal/CiviCRM) will far outweigh the benifits realized by the integration of applications accross web-services in terms of costs saved and passed on to technology owners and innovations in technology and services.

Integration accross web-services and web-standards is relatively costly

• Web applications that are not built from the ground up to be integrated will never play nicely with one another. Let me repeat: if an open-source application is not built to be integrated with your web-application it probably isn't worth the effort to try to integrate it. This renders 95%+ of open-source web applications useless for those looking to leverage the work of other communities.
• If an application has a strong API it is still tricky to integrate. Even integrating with CiviCRM, an application that was built from the ground up to interface with CMS's and shares the same web-app environment as Drupal, it costs us 2-10X more to integrate with it than it does to integrate with a standard Drupal module.
• The most cutting edge private sector web-service and web-standards are not that advanced. We still don't have workable single sign-on solution, the cutting edge of semantic information interchange across the web is to embed it in XHTML, the hottest API's from SalesForce and Flickr haven't made much of a dent in the marketplace, and please don't get me started on the semantic web.

The market currently prefers a single integrated stack

• The majority of the market for web-technology services is owned by companies like Kintera, GetActive, and Convio that serve as one-stop shops for virtualy all an organizations web-technology needs. They have trained technology owners to make purchasing decisions under the assumption that they can cut a check to a single entity that will provide and support a complete "solution". I.E. there is not much point to shopping around for "best of breed" services to integrate, "just give us your business and all your technology problems will go away". This creates an uphill battle in the marketplace for vendors selling what will be seen as "piecemail" solutions created by amassing various web-technology providers products across web-services.
• There are huge unanswered usability concerns created by integrating together two different applications. This is espcially felt in functionality that is presented to an organization's contituents. Technology owners demand a seamless user-experience across their user facing application space (CMS, event tools, community tools, etc). In the future as more and more functionality moves out of the back-office and onto the web these concerns will only increase.
• Open-Source vendors eat costs when integrating third party services, mantaining integration, and licensing software, so they have economic incentives to service a complete pre-integrated stack of technology instead of servicing a suite of other providers products integrated over web-services.

The future of the application stack and the role I think webservices will play

I hope and expect that in the next year the CS/CiviCRM/Drupal stack will evolve to a point where it can compete head on with the likes of Kintera, GetActive, and Convio. When this happens open-source vendors will grow into full blown ASP's that will be able to sell services that undercut the current market of proprietary service providers and will be able to grow downmarket to smaller organizations and horizontally to for-profits with overlapping technology needs. With so many organizations and vendors based on the same codebase it will create a very efficient marketplace that supports application development and services. It will also open up the marketplace to anyone wishing to specialize their services towards a vertical, sell data services, or offer 'best of breed' applications. Since the majority of the vendors business will be based entirely around customization and hosting / support and not licensing fees to support product development and sales, they will be much more likely to partner with 3rd party providers or create specialized services themselves. Over time as web-standards evolve the third party services and specialization will grow increasingly important in the marketplace. And then we can all live happily ever after....

A lot of full time Drupal/CS consultants I've been talking to here in Vancouver have been sharing concerns about how to meet the needs of their clients while still being able to contribute code they development back to the Drupal community. The general assumption is that most clients are oblivious to the mechanics of open-source communities and assume that they are paying simply for an engineer to develop new functionality and ignore all the time required to work with the Drupal community to make sure contributions and patches are accepted and merged back.

I think the simplest solution is to figure out a way to asses costs to forking code that can be communicated to customers upfront when contracts are negotiated.

How about this estimate?

1. Costs to mantain your own forked module: 25 developer hours X $100 an hour X 2 times a year = $5,000 a year per module.
2. Open-Source development resources lost: 5 hours per patch X $100 an hour = $500 per patch.

Using these estimates I would think that consultants should be able to justify adding in a line item to their contracts up front to cover their costs to contribute their code back to the community. Do you think this will work?

I am posting from the basement of 800 Robson Center Vancouver BC at the Open Source CMS Summit / DrupalCon 2006. This is without a doubt the most fun work-travel event I've taken part in (I've done more than twenty in the past year). One year ago at the DrupalCon in Vancouver there were about a dozen of us. In Portland six months ago there were thirty or fourty. Today there are well over one hundred Drupaler's in attendance hanging out, learning, hacking, discussing, drinking beer, and scheming for Drupal world domination.

The Drupal software, the user base, and espescially the economy around the platform have seen an explosive growth in the last year. When we started CivicSpace a year and a half ago there were only a few of us who made a living in and around Drupal. Today there are well over one hundred people employed to hack on Drupal between the contract firms and the user-developer base. With a little napkin math I estimate that in a year the Drupal economy has grown from ~$500K a year (10 X $50K) to well over $5M a year!

Despite this phenominal growth I have some concerns about what the next year holds in store for the Drupal platform and the community around it. As I see it, most of the value created by the Drupal community that vendors and consultants rely on to sell as services to customers come from unpaid core contributions. Examples of this are the majority of 4.7 improvements: multiple block regions, new forms API, installer work - these were all unpaid contributions to the community by volunteers or pro-bono work from Drupal firms. At the same time, many of the seasoned Drupal core hackers are getting job offers left and right to come and do Drupal consulting full time. This is creating a scenario in which while many more people are paying their bills through Drupal hacking and more and more business are built around business value created by the Drupal community, it is not getting any easier to make sure the heavy lifting on core work is getting done. For example: I know of no funding availiable to support key Drupal core projects such as continued forms API work, actions & workflows development, CCK, and most importantly; usability improvements.

In the next year I am expecting the economy around Drupal to continue on it's fantastic pace. I would not be surprised if by 2007 the economy was well over $20M annually. My big question here in Vancouver is: What can we do now to make sure that some of the money coming into the community over the next year is put back in to supporting the core work that we as a community are relying on?

Why?

• save development effort across projects
• collaborate on fundraising, marketing, etc.
• deliver complete solution across application domains on one web framework: CMS, CRM, Course Ware, and Social Apps

What?

• Phase 1: light integration (single sign on / common installer / unified interface)
• Phase 2: Leverage Drupal frame-work as appropriate

It will work because

• Funders love joint projects
• LAMP is way cheaper than JSP/J2EE
• This is exactly what CTO's / CIO's at Universities want
• We have the community! (Drupal: 55,000, Moodle: 8,900, CivicSpace: 2,000 installs)

Precedence

• Sakai / uPortal / OSPI
• CivicSpace / Drupal / CiviCRM

Challenges

• application integration
• business models

Roadmap

1. Project leads sign on
2. Line up University partners (some paying members)
3. Get industry partners to back project
4. Merge fundraising targets
5. Raise seed round from private donors to investigate
6. Create prototype integration
7. Raise real money from foundations
8. Execute
9. Win