wiki

May 07, 2007

I'm at the IBM Mashup Summit in San Francisco today. As we are within the bowels of a large enterprise, there is a process to follow to get wifi access, so I'm offline. We're here to talk about mashups within the enterprise. With all the innovation on the web with mashups and widgets, real work needs to be done on standards, identity, process and security to bring them into the enterprise. We aren't just talking about technical work to make things work, but how to market it before insecurity FUD curbs innovation.

Dion Hinchliffe phoned in an introductory talk about what he is seeing in the space (I'll try to find notes to link to, and update this post later).

Then Pete Kaminski (Socialtext CTO & co-founder) and I gave a little talk about the things we have seen, done and questions we have. Unfortunately, Open Data is being seen as enough in this space. Be like Flickr, just put up an API, let people innovate, and that's good enough. But it isn't good enough for enterprises, which is an opportunity for us to work on standards that may conversely enhance the consumer web. For an enterprise, to develop upon a service, they need to know if their effort is at risk, as the API may change. Especially when services are built upon services upon services. Enterprises also pay particular mind to switching cost and lock-in risk, and standards and open source provide ways of reducing cost and managing risk.

Mostly we talked about Amo, which means "to carry" in Hawaiian and is a REST API for wikis we hope becomes an ad-hoc standard. It incorporates the Atom Publishing Protocol thanks to some good work Chris Dent did over a weekend. Unfortunately, the folks really working on this stuff are up at our hackathon in Vancouver this week. But it gave us a chance to share what we have heard and not from enterprises over the last four years. Customers have stronger needs to integrate with directory systems for single sign on, and despite our efforts to make auth pluggable, the lack of standardization in this area is a problem not just for deploying a wiki -- but signals the complexity and perhaps greatest risk in enterprise mashups, that of identity. When a mashup platform has multiple services and multiple logins, where and how are they stored is an exponential problem that puts security and system cost in conflict with usability. We didn't get customers coming to us asking for mashups in numbers, but we did get people asking for data to be available and offline editing. We created RSS and Atom feeds for every page, tag, search query, watchlist, weblog and wiki. In absence of other clients, we used the Atom API for offline editing using Ecto, a blog editor. Most recently, we created SocialPoint for Sharepoint portal integration using our SOAP API. With the REST API, we worked with Jeremy Ruston to create Socialtext Unplugged for offline wiki reading and editing.

Pete made an interesting point about the currency and quality of data that reminded me of a post by Allen Morgan I read yesterday. Pete pointed out how the rise of the convenient cell phone has changed user expectations for call quality within land-lines themselves. Allen is exploring similar trends in audio and video: fidelity declines with the rise of convenience. Pete gave the example of how a user of Socialtext Unplugged can board an airplane to Hong Kong with a reasonable expectation they will be working with less current information the further they travel. What user expectations and education will they have when using mashups across different data from multiple processes. This is an important question because it also informs how expensive it should be to build and operate these systems. Rod Smith suggested there should be a "freshness dial."

I emphasized that there are some areas you don't want to automate, such as merging revision conflicts, because people are better than algorithms for many things, and suggested other service providers borrow from some elements of wiki design like revision history.

I shared our experience with open source application licensing. From the conversation, I think people understood the need for a different license for open source web applications compared to infrastructure. But it also was clear to me that I've not communicated our current status, as someone in the know asked if we were "Open Source." Nobody owns the term and can modify it in their own way, but there is a significant role for OSI to accredit project as OSI Certified. Socialtext is almost six months into the process of getting it's license OSI Certified, we don't claim we are yet, but we do say rightly we are a commercial open source provider. We are about to submit a third revision of our license, so I write more later, but if the process concludes in the negative, we will choose a different OSI license. Not because it will suit our needs, in fact it will decidedly not, but because of the role we want to play in the community. We'll see what the other 15 MPL+Attribution projects do. But attribution is an important issue for mashups, and people here seemed to be in favor of it.

Stephan from Kapow technologies sees the stack as Mashup builders like QEDwiki, Teqlo and Excel and Mashup enablers like Kapow and RSSBus.. Because we don't have UDDIs and WSDLs of the web services world, we need service discovery through a central service repository and builder specific repository. How do I find the data I need and get it into the format I need? Within the enterprise, users want to be able to get to data without involving IT. An example of this is IBMs Mashup Hub, and while more service descriptors are needed, people just want to grab two values off of different sites (using Kapow's web-scraping) and put them together in Excel or SocialCalc. Need to communicate through WS* (he assumes SOAP is what legacy speaks. Someone pointed out that at Mysql conference nobody knew about SOAP, and he countered that people in Europe don't know REST), REST, RSS/Atom feeds, Atom Publishing Protocol, APIs. And access the data through HTTP and HTTPs. Suggested solution: Define microformats to describe each type of service. Define a simple way to inform Builders of the existence of services and define a simple way for Enablers to request service information from central repositories.

At a certain point the notion of having a market of services that people could purchase on a granular billable basis came up. I suggested to start from the opposite side, encouraging the commons. Or more specifically this group could go to Creative Commons and try to host a directory of CC licensed APIs. We also discussed availability, and I pointed out that in other industries we would start with conversations about standardizing SLAs.

Paul Raymond who is in the commercial division of AccuWeather, which provides weather info to 106 million Americans each day. Their primary asset is their brand, they copyright much of their material and want to syndicate under control. Web scraping creates new business models for them, even if it is just linking back. They co-brand over 20k affiliate sites, provide a number of mapping web services and work with other mapping services, have a number of widgets and more. Other business models: subscription and fixed pricing that is secure and authenticated -- or CPM-based control content, campaign, source and cost. Their basic approach is let people hack upon it, but largely encourage marketing attribution in return.

I had to leave before the afternoon sessions by SnapLogic, Jeff Nolan, Reuters and Mashery. We still haven't really talked about security, or the marketing thereof, which is the elephant in the room. It will be interesting to see if a common roadmap emerges.

A guy from the EPA was asked about politicizing of data. He shared how there is a law where you can dispute the bias or accuracy of data and gain resolution. He told the story of how a US Satellite over the north pole started picking up anomalies in ozone levels and scientists believed it was impossible so they normalized the data syndicated. It wasn't until British scientists used balloons to find unreported change that they opened up the logs and corrected the feed.

Data is political and when you have so much change it is the politics, as much as the technology, that needs to be worked out by the community.

March 22, 2007

Nick Carr reports on two studies of Enterprise 2.0 adoption by large enterprises:

Some hard data is coming out this week on the adoption of Web 2.0 tools
by companies. Yesterday, Forrester released some results from a
December 2006 survey of 119 CIOs at mid-size and larger companies. It
indicated that Web 2.0 is being broadly and rapidly brought into
enterprises. Fully 89% of the CIOs said they had adopted at least one
of six prominent Web 2.0 tools - blogs, wikis, podcasts, RSS, social
networking, and content tagging - and a remarkable 35% said they were
already using all six of the tools. Although Forrester didn't break out
adoption rates by tool, it did say that CIOs saw relatively high
business value in RSS, wikis, and tagging and relatively low value in
social networking and blogging.

McKinsey did a broader survey of 8,300 executives with similar demand and adoption patterns:

It found that social networking was actually the most popular tool,
with 19% of companies having invested in it, followed by podcasts
(17%), blogs (16%), RSS (14%), wikis (13%), and mashups (4%). When you
add in companies planning to invest in the tools, the percentages are
as follows: social networking (37%), RSS (35%), podcasts (35%), wikis
(33%), blogs (32%), and mashups (21%).

But the highlight of the Forrester study for Nick and Richard MacManus is CIO attitudes towards incumbent vendors vs. startups.

74% of CIOs said they'd be more interested in investing in Web 2.0 if
all the tools were offered as a suite, and 71% said they'd prefer the
tools to be "offered by a major incumbent vendor like Microsoft or IBM
[rather than] smaller specialist firms like Socialtext, NewsGator,
MindTouch, and others."

Nick concludes: "You can bypass the CIO on a small scale, but it's difficult to bypass
the CIO when it comes time for a company to standardize on a particular
product and vendor." Yup. It has always been the case for enterprise software.

CIOs of large enterprises will largely give preference to the incumbent vendors they have relationships with to realize economies and standardize architecture. Especially when almost all of their budgets are sunk with maintainence fees of said incumbents. Part of expressing preference for suites is that suites are now available, beginning with SuiteTwo (Socialtext, Six Apart & Newsgator best of breed core offerings). I find the results of the survey very encouraging -- that SuiteTwo is a comparable preference to Microsoft or IBM.

Some CIOs will go what what (or whom) they know and stick to existing vendor relationships. That's why we created SocialPoint for the best-of-breed wiki to work with Sharepoint. As Lawrence Liu from Microsoft said: "More and more SharePoint customers who want advanced wiki functionality are looking to the specialized wiki ISVs like SocialText to provide it with an integrated user experience in SharePoint by way of 3rd party webparts."

Euan's subtle insight on how to do Enterprise 2.0 is that there are powerful grassroots energies to not only tap into, but if you impede them you risk your deployment more than anything. While there is a certain inevitability of Enterprise 2.0 proliferation thanks not only to SaaS, but namely open source, his message is less about the tools than the demand for them and practices that make it work.

Dion Hinchcliffe explores this and notes "Those that represent to be doing Enterprise 2.0 solely through tool
rollout and no infrastructure remediation will almost certainly be
among those reporting less encouraging results."

This is all in the context of the alternative to how this post began. Besides large enterprise CIO preferences, there is the bottom up. And smaller companies.

Lee discusses the challenges of a completely bottom-up approach:

On the technical level, the integration challenges are non-trivial:

identity / Single Sign On (SSO);

internal application integration;

legislative obligations for data retention, privacy and audit; and,

availability.

But the integration of people, practise and (dare I say) process is even harder, with challenges such as:

devolving responsibility and promoting a DIY culture;

encouraging people to grow their own internal and external networks;

stimulating conversation and debate by overcoming fear of exposure; and,

for many people, simply overcoming the idea that any form of online communication beyond email is "not part of their job."

Those challenges become opportunities when you have buy in from the top down and IT supports. And when you have actual leadership, as Suw Charman noted: you have the best adoption strategy. Lee specifically explores SaaS and rightly notes that it isn't a fit for many enterprises that have customization needs. He sees two trends in SaaS that have potential to close this gap:

The first is in the area of specialised appliances or systems that
live inside the firewall, where they can happily integrate with
internal apps ad data, but which can also be updated and fed by managed
connections that extend outside the firewall. The Socialtext managed appliance seems to be a good example of this approach, which is a workable compromise between SaaS and purely internal systems.

The second area is enterprise software that takes advantage of
managed connections with web services to add value to internal systems.
Movable Type was a
pioneer of this approach with its blog ping service to feed a public
list of recently updated MT blogs. Their impressive roadmap for the
enterprise version of this market-leading blog platform suggests they
will take this a lot further in MT v4.

You really should go read his post, at least for the Star Wars metaphor. He concludes that SaaS still has a way to go:

...But the emphasis will shift from software, which is just a mechanism,
to services, which is the actual product. Some of these will be new and
imaginative forms of what we might recognise as applications, but many
will be pure data or data transformation or sharing services. But whilst we will see adoption among SMEs for cost reasons,
enterprises will not embrace SaaS for their mission critical systems or
data until such a time as we find robust solutions for the key
integration and data management challenges.

I see promise on resolving some of these challenges for the enterprise from innovations borne on the web. OpenID is a good start for identity and authentication, and will find its way into the bowels of enterprise directory authorization. RESTian APIs are shaking up pre-conceived notions of SOA. Open Source provides more options for not only these challenges, but is the dark horse for Enterprise 2.0 the adoption race.

March 14, 2007

Matt Mahoney spends most of his time working with enterprise wiki customers, cultivating adoption and best practices. In his most recent blog post, he provides a practical look at how enterprise wikis differ from Wikipedia. Wikis evolve in the context of corporate culture and inter-personal communication styles, for good or ill. The sense of ownership people have over pages is different than the norms that have arisen for Wikipedians. After discussing work conversations and group memory in wikis, he leaves us with some tips:

5 Simple Tips* Assign responsibility for workstreams, and as a result, pages* Use comments to add your thoughts without crowding out the person stewarding the task* Rely on abundance, use talk pages for lengthy discussion, then re-factor the discussion into a joint page* Pair live on IM or a screen-share, alternate note-taking* Have a meeting, take notes, post the output

March 06, 2007

As I stated quick
emphatically during my "SharePoint Collaboration and Community Tools"
session at the European SharePoint Conference last Tuesday, the wiki
functionality in WSS 3.0 was not designed to compete directly with
best-of-breed wiki products like SocialText,
but rather, it's the integration of a plethora of collaboration and
community features that make WSS 3.0 and MOSS 2007 best of breed as a
whole. My presentation slidedeck is available for download here.

In fact, SocialText is the process of developing a new version of their SocialPoint webparts
that will be compatible with WSS 3.0 and MOSS 2007. The key competitive
advantage of SharePoint has always been and will continue to be in the
foreseeable future the breadth of integrated collaborative and
community-based applications that are provided out of the box or can
easily be developed with SharePoint rich platform services. I believe
that the built-in wiki functionality is sufficient for a very large
percentage of our customer base, and many customers have indeed
standardized on the SharePoint wiki as part of their overall
standardization on SharePoint as the enterprise collaborative
application platform. More and more SharePoint customers who want
advanced wiki functionality are looking to the specialized wiki ISVs
like SocialText to provide it with an integrated user experience in
SharePoint by way of 3rd party webparts.

Mike Gotta's gut tells him that SharePoint will enhance its wiki and Microsoft will crush its erstwhile partners with a forthcoming release. I too fear this waking giant. Part of my job is an uneasy stomach. But I did add this comment to his post:

Yes, we expect our value to erode release-to-release, if we don't continue to release ourselves. Which we do in a timeframe measured by days, not years. As first to market and first to feature, we have to keep moving to remain the best-of-breed vendor. And clients benefit from choice.

"It's easy for people to use "that function will be in the next release" to deflect support for business requirements that may result in tremendous short-term value."

Isn't that the opposite of what Lawrence did in his blog post? I'm sure he could have, and your gut could be right. But I imagine it is based largely on an embedded reaction to prior FUD.

February 20, 2007

Back in November, Andy McAfee shared a great wiki case study from Avenue A | Razorfish. They adapted MediaWiki to meet their needs. Leveraging open source, a great approach for a company that builds custom Intranets.

… Our wiki did not take a full year to build and the part-time
developers were bench resources. In other words, it did not cost us
$100,000 as Jeffery implied. Furthermore, enterprise 2.0 as coined by
Andrew McFee is not about cost but about what the software does for its
users and how they shape the software themselves.

Commercial enterprise 2.0 software like Socialtext, Brainkeeper and Atlassian Confluence are great options for some business scenarios and we often recommend
them to our own clients. But in other cases, simply modifying open
source sofware can get an organization what it needs. Furthermore, by
modifying mediawiki we were able to get exactly what we needed. Most
importantly, by virtue of how it is being used, we know that it is
social software in an organization - and that's the most important part
of an enterprise 2.0 solution.

Anu Gupta of Headshift attempted to comment (as did I and I'm stealing the structure of this post from Anu):

Shiv - not sure I agree with you…

I think you’re lucky (or unlucky) in having bench resource available
- a lot of companies aren’t in that situation and have a constant
battle to get developer time. So, faced with that situation - what is
the cost of having 2 developers available, part time, to develop and
look after your mediawiki instance over 18 months ?

Secondly, would spending the relatively small amount on an unlimited
license for Confluence ($8,000) or Socialtext, and getting out of the
box AD integration, search and granular permissioning, represent better
value than developing it from scratch ?

Also, developing inhouse commits you to a codebase that with an
audience of just yourselves (until you release it out to the community
?).

I can see both sides here. Jeff's point is that MediaWiki wasn't designed for Intranet use out of the box. I believe there is truth to this, that MediaWiki will always be optimal for running a public online encyclopedia or similar community.

But you can't slap down open source development on the basis of cost alone. Going with a proprietary vendor inherently restricts freedom -- both through lock-in and the ability to extend. Open source enables a company to both manage risks, share risks across a community and adapt software for their situation. Engaging internal developers also engages core stakeholders that can help wiki adoption.

I also find the cost argument to be misleading. The closed option has a license cost, the open option has no license cost. But the customer's customization requirements would have to be met somehow, and who knows how the buy vs. build works out in this case where pricing isn't transparent.

Anu's System Integrator perspective provides a third way, where a third party gains economies by providing solutions across a base of customers. But to remove the question mark at the end of his comment, so does an open source community. It seems Razorfish benefits from having the bulk of its codebase be community maintained, and I would suggest sharing their extensions are in their best interest. I'm not questioning the value of such integrators, each has their own proposition and value add, but the customer would be better off if an SI serviced codebase was, again, open source.

The fourth way involves me tooting my own horn. If Razorfish started their project today, they could use Socialtext Open and get the best of both worlds. The best of breed enterprise wiki and the freedom of open source.

We chose a commercial open source business model because it strikes a balance between freedom and profit. Not because we are hippies. But because it is in the best value for end customers. As first to market and first to feature, we continue to innovate and there is the chance that one day Razorfish would find having us service the software to be a valuable option. But that is up to them.

When competing in a market full of choice, you have to be a choice leader. Not just in providing on-site, Appliance, SaaS and open source deployment and licensing options. But enabling your customers to make their own choices.

January 30, 2007

UPDATE: An interesting related project by Penguin Books is A Million Penguins, letting anyone edit a book to be published. The wiki is down at the moment, but PaidContent notes it began with “It had snowed, and was now raining. Gritty slush covered the pavement. Sharp crystals of snow decorated grass.” Reuters notes the challenge is finding “believable fictional voice” within the mass collaboration. This was a big challenge for group editing of the Wired Wiki story.

The last chapter of Don Tapscott's new book, Wikinomics, invites readers to write it: “Join us in peer producing the definitive guide to the twenty-first-century corporation on www.wikinomics.com.” Today we launched a Socialtext wiki for the Wikinomics Playbook, where people can not only learn about the power of mass collaboration, but participate in it. The book is already one of the fastest selling business titles and is an excellent primer on how models of collaboration are unfolding from open source to blogging to wikis in the enterprise to enable people to participate in the economy like never before.

The second to last chapter is about enterprise wikis. Half of it discusses how Best Buy is using a wiki knowledge-base for the Geek Squad. The other half is an interview with yours truly and shares some of Socialtext's success stories. The first chapter is available online as a pdf.

This is a great example of how a book can be augmented with a wiki, as most books are out of date by the time they are published, never quite finished and have the potential for participation. Last month we helped Larry Lessig share the entire Code 2.0 book in a wiki. I expect that soon such commons-peer production, a wiki for every book, will be common.

because Wikipedia is the Internet's encyclopedia, many of the articles
have included resources from the Google searches on that topic. Over
time, Wikipedia has been slowly eating the entire Web's knowledge base
until it becomes itself a faster, better, and -- most critically --
unspammed reference matter of what are the relevant and valuable
resources. And unlike mere link directories, it doesn't simply list
links, it tells a story about them.

The second point, which supports the first, is people are adding these terms to their queries to get better results. People may prefer results not just validated by link count by others, but with edits by others.

This is the flip side of social search, where not only relevance is are improved through social means, but results.

November 30, 2006

These new wiki and blog based platforms are an example of the
promise of Web 2.0. They introduce a whole new way to build
collaborative, interactive, web ready applications that can be hosted
"in the cloud" or inside the firewall.

Platform shifts happen every 10 to 15 years. We may be witnessing
the start of a new platform shift with Web 2.0 style blog and wiki
platforms.

i hesitate to call what we do a platform yet. It is hard to think of a startup that started and remained as a platform. Instead we are focusing on being a killer application first. Apps that gain widespread adoption become attractive for others to develop upon, and if managed right, become platforms.

That said, Don is right that we are at the beginning of a platform shift. Wikis and Blogs have from their very beginning afforded open source and open APIs. They make great containers for orchestrating web services to form composite applications, or for being mashed up elsewhere. And more importantly, they are collaboration and communication tools that demand and enable redesign of applications. Not just slapping them on a web page.

How can more people be empowered to do such redesigns, for print and for the web?

My answer is based on my
opinion that any solution needs to be
Document Centric. I believe an online spreadsheet is an excellent
starting point for building a mashup fabric: a document into which
a range of online services can be combined.
To that end I downloaded and installed wikiCalc
and tried to integrate my sparklines service
into a spreadsheet...