Search Results for: wikis

post

Is SaaS Dead? No. Neither is Debate.

cemeteryWe’ve had email dead, resumes dead, wikis dead themes, now it’s apparently time for the SaaS is Dead meme, thanks to a recently published Gartner report.   My favorite quote from the report:

SaaS is not a panacea, and companies need to evaluate and understand the trade-offs that SaaS presents

Indeed. Here’s another quote from Gartner VP Rob Desisto:

If you’re a small business with no IT staff then the math is a lot easier. You need to buy the hardware. With a larger company, the math doesn’t always work out in favor of SaaS.

Now, where have I heard that before?  Wait… I said it, 4 years ago:

…While it’s easy to declare that for small businesses without their own IT resources there is no better option than SaaS, there is no clear “winner” for large corporations. There shouldn’t be. This is not religion; it should be business decisions that these organizations have to make individually. Analysts fighting the SaaS vs. On-premise war often forget that software exist to resolve business problems. As Charles so eloquently points out, it’s the complexity of these business processes, the need for customization, the number of user seats..etc that matters, and as we move up on this scale, increasingly “traditional” Enterprise Software is the answer. I happen to believe that eventually SaaS will grow up to meet those requirements, but am not going to guess how many years it will take. In the meantime the SaaS-fans (admittedly I am one) can claim that SaaS is the future – but that does not mean Enterprise Software is dead.

OK, ego trip done, let’s look at some of the specific points that sparked a debate between Krish  @ CloudAve and Ben Kepes:

The TCO Myth

Gartner argues that long term TCO of on-premise software can be lower for businesses that don’t upgrade often. Krish’s counterpoint is that businesses that stay on obsolete versions of their systems will fall behind competitors.  Ben argues that many businesses are simply satisfied with their current system functionality and would derive little value from upgrades (well he refers to moving to SaaS, but that was not the original point by Gartner).

My take: sorry guys, it’s not so black-and-white.  Yes, many businesses avoid software upgrades like the plague, but not necessary because they would not benefit from it: it’s all about avoiding the major cost and business disruption traditional Enterprise Software upgrades bring about. (As a background, I spent the 90’s selling and implementing SAP solutions. I still chuckle when I hear there are SAP consulting teams at my 1990-93 clients: the upgrade cycle never ends)

SaaS typically comes with more subtle and more frequent updates that don’t disrupt business.  Now, let’s be fair: the SaaS market is still quite nascent, despite the fact that Gartner is ready to bury it. Our experience is with seemless Google and Zoho upgrades, or not-so-seamless but still not disruptive Salesforce.com, NetSuite ..etc upgrades.  There is still nothing on the same magnitude of a SAP or Oracle Enterprise Suite, so we really do not have a lot of realistic comparison on that level…

For further details I suggest Ray Wang’s excellent piece on How To Compare Total Ownership Costs.

The Pay as You Use Myth

Gartner says the old enterprise practices are seeping into the SaaS market and we are seeing push for long-term, multi-year deals with upfront payments.

Krish argues that many enterprise customers actually prefer to pay long term to avoid the hassle of monthly billing, while Ben points out the root cause of the issue is SaaS vendors not having the right tools for more granular use-based billing.

Both are right, I don’t even see this a debate (?).  Years ago I had been a NetSuite customer, and was given several choices, with multi-year contract carrying significant discounts.  But still, the plans were mostly seat-based, with no chance to adjust downward and not enough flexibility to account for functions used / not used.   But let me say this: a lot of what we’re saying today is just business decisions, SaaS providers have better technical bakcground to offer very granular, real-usage based pricing for two reasons:

  • They can actually monitor what is being used (unique vs concurrent users, actual functions not just major modules)
  • They can invoice accordingly – the systems are now available, and I think competition will push them t create the business framework.

Coincidentally, NetSuite just announced their integration with Zuora, the billing system for the subscription economy. This is an offering for subscription-based businesses who uses NetSuite – in other words NetSuite’s customer.  Now, what I really wonder about is whether NetSuite will take this opportunity and consider themselves a customer / user of Zuora’s services: i.e. step up the plate and offer true usage-based subscription models – most likely as an alternative to the current ones.

The Shelfware Problem

No, for this to come up as a SaaS-specific problem is just pathetic. Shelfware is as old a concept as Software licencing: it’s the phenomenon of being locked in to more user seats and entire modules you don’t use, often without knowing about it.  Here’s a choice quote from Gartner VP Rob Desisto again, although he used it in another context:

many organizations have CRM already because it was bundled with their ERP licenses

There is nothing inherent in the nature of SaaS that would promote shelfware, in fact as I‘ve just pointed out above, technically SaaS vendors have better ability to monitor actual usage than the major nightmare of software audits in the on-premise world.  There are good initiatives, like RightNow promising to end shelfware, and I trust competition will lead to more of this.

Again, I offer two great pieces on the subject by Ray Wang:

The debate is on – feel free to chime in.

(Cross-posted @ CloudAve)

post

Forbes Gaffe: Prints Private Chat Between AP Reporters. How to Correct Online Publications.

The Forbes Gaffe

Ok, now that I got your attention with the title, this is about more than Forbes’ Royal Gaffe. But first things first: Forbes mistakenly printed a “story”, (update: original deleted, see saved copy) which isn’t a story but private chat between two AP reporters, and should not have been published at all (hat tip: Mathew Ingram):

Associated Press

Swiss arrest Polanski on US request in sex case

Associated Press, 09.27.09, 10:41 AM EDT

i checked already, and so did zurich. they say the question is irrelevant. he answered me with the quote i used, about we knew when he was coming this time. he’s been here many times in the past, we think.

thx brad. aptn is aware, but unfortunately won’t make it in time, but is hoping to catch tail end.

i’m pushing out another writethru with some more background details before press conference.

no surprise, new york is really hot on this.

they particularly want to know why now. (has he never set foot in switzerland before?) sheila, theorizes that’s because they’re under intense pressure over ubs and want to throw the U.S. a bone, but can yo ucheck with justice department sources there?

is frank around too, or are you alone?

u can tell aptn press conf 1700 (15 gmt) in bern at the parliament

i’ll watch it live on internet

Clearly, somebody at Forbes / AP must be sleeping, since the “article” is still online after a full day – but let’s assume they will wake up and remove it, so I’ve  saved it on Zoho Viewer.  But let’s use this opportunity to discuss something more important.

Airbrushing Online Articles After the Fact

I borrowed that title from Jeff Nolan who discusses the case of The Washington Post materially changing an article after the fact, without notification:

It’s one thing to correct references or relevant facts but to materially change entire sections of an article is alarming and undermines the central argument that newspapers themselves make about why they are essential systems of record for society.

The record of an event is only changing as the timeline plays out and new facts and arguments emerge, which may serve to invalidate previous reporting and in that case should be noted as new content, not airbrushing of already published content. At the very least a record of corrections should append each online story when necessary rather than flagrant material editing of content done “under the cover of darkness”.

Newspapers must recognize that the public trust they cherish is at risk whenever they rewrite an article that is already published online.

I fully agree with Jeff, in fact, let’s just extend it to any form of online publication, including blogs.  For minor changes we can always use there is always good old strikethrough. Of course if you do it a lot your text becomes unreadable, so for more changes, the right approach is to indicate the change and list the previous version of the story.

But wait!  We already have the technology to automate this!  Wikis are known for full version control and trackability, any Wikipedia reader can follow how much-edited article took shape by clicking on previous releases.  The WordPress editor has for a while offered rolling back to previous releases – but that’s just for the blog author.

Here’s a simple proposal:

Make version control available to readers. I don’t mean the tiny edits while you shape up your thoughts.  There should be a check-mark for “major edit”, and if you click it, it should cause a “Previous releases of this story” link to appear in a prominent place, at the top or bottom of each article.

This would go a long mile toward improving blogs’ credibility (and yes, newspapers can do it, too).   Oh, and just to clarify: I’m discussing content change here.  The Forbes story is different, it was a mistake, and I fully agree it should be removed when (if) Forbes / AP wakes up. (Update: they did.)

(Cross-posted @ CloudAve )

post

SocialText Becomes Really Social

Socialtext, the enterprise wiki company is no more… a wiki company, that is.  Not since Socialtext 3.0, the new release announced today.   Founder and Chairman Ross Mayfield calls his new baby a Connected Collaboration Platform, that’s modular, built on a widget framework, and consists of:

A fourth piece, Socialtext Signals is in the works, in private beta testing – I guess we could call it Twitter (Yammer?  ESME?) for the Enterprise.  Actually more, since it involves active microblogging – quick messages – as well as pulling in what users do elsewhere (FriendFeed?)

The platform is flexible, easy to customize via widgets, clearly the vision is that in an enterprise environment actionable information is pulled in from the transactional systems, too – i.e. ERP, CRM.

Knowing Ross as the uber-social guy something tells me this is what he always wanted to to: create Social Software.  But I tend to agree with Jevon MacDonald, who differentiates social software from the wiki, which is primarily a collaboration tool.  So Ross was really in the collaboration business and given his name became synonymous with wiki evangelism, he will no doubt have a hard time changing that image. smile_wink

This is not to say the wiki part, should be neglected… It is the primary collaboration facility for anything not well handled by process-driven, transactional systems, and all this social layer is just the glue that holds it all together.  (Hint: you will hear a lot more about Glue soon).

I had in the past been quite critical of Socialtext’s wiki component, and am looking forward to revisit it, as part of our wiki-series in the coming weeks @ CloudAve.  In the meantime, enjoy this video:

post

AdBrite = AdDumb. Why You Should Avoid In-line Ads, Whether Contextual or Not.

Here’s a classic example for stupid “contextual” in-line ads:

 

Clicking on the “feature” link in this article brings up skin care products.  The “tool” link in the first line points to Honeymoon Planning Services.  Here are some more cases of “contextual” advertising gone bad:

 

But all these mishaps aside, here’s another reason why you should avoid such in-line hypertext ads:

They seriously reduce readability. This article happens to be quite important, so the first thing I’d like to do is click on the link to the Google tool that allows me to protect my account (you should read the original article to understand what’s at stake). But I can’t – the link is hijacked. In fact I can’t even tell if there is any intentional, relevant link in this post.   Blogs, wikis, you-name-it: online writing is all about linking and relevancy. But there’s only so many we can deal with: when your article becomes a link-jungle, it becomes impossible to find the meaningful ones, supporting your message.

See also: Ridiculous Advertising – or the Case of the Hijacked link

post

Email is Not in Danger, Thank You

Yet-another-email-is-dead (OK, just in danger) article, this time by Alex Iskold @ ReadWriteWeb.  Alex adds Twitter‘s increasing popularity to the standard “reusable” arguments: teenagers using IM, or increasingly SMS, and most recently Facebook instead of email which they find cumbersome, slow and unreliable – hence email usage will decline.

I beg to disagree as I did before, and before.  Sure, I also get frustrated by the occasional rapid-fire exchange of one-line emails when by the 15th round we both realize the conversation should have started on IM. Most of teenagers’ interaction is social, immediate, and SMS works perfectly well in those situations. However, we all enter business, get a job..etc sooner or later, like it or not…smile_wink Our communication style changes along with that – often requiring a build-up of logical structure, sequence, or simply a written record of facts, and email is vital for this type of communication.  As much fun Twitter may be, I rarely have (or see) serious ongoing discussions there  – in other words Tweets are in addition, instead of email.

Email in business is being “attacked” from another direction though: for project teams, planning activity, collaboratively designing a document, staging an event… etc email is a real wasteful medium. Or should I say, it’s the perfect place for information to get buried. This type of communication is most effective using a wiki, or an increasing number of online tools supporting native collaboration.  Yesterday I reviewed a startup CEO’s ppt deck, and it took us 4 rounds of emailed versions of the same presentation – it would have been a lot easier to collaborate on just one “master” presentation in Zoho Show.

So yes, I agree with Alex, even in business we’re offloading stuff off email.  But email is far from dead, or even in danger, and it won’t be any time soon. We just have to learn to use the right tool in the right situation. As usual, Rod Boothby says it better in a single chart:

Rod’s chart is almost two years old, but still valid – perhaps I would update it to say “Wiki and collaborative documents”.  My own post here is a slightly updated version of an older one from last year, which in turn was an almost verbatim reprint of another one from July 2006. I rarely re-post old stuff, but in this case I felt it still made a valid point.  Next year, when someone brings up the “is email dead?” question, I’ll dust it off again. smile_tongue

Zemanta Pixie
post

Wiki Review or Rant?

I am deeply interested in wikis, and business oriented ones in particular, in fact was considering doing a fairly detailed comparative study, so I got really excited seeing on twitter that Tom Raftery posted an Enterprise wiki review. Too bad it’s not a review; it’s a rant that lacks any methodology or real comparison.

He goes at length describing the installation nightmare:

The setup of the Confluence wiki was far from straightforward. It took two of us the best part of a day to simply install it. Remember that as I was doing this for it@cork, this was not billable time. I was installing it on my own server and because Confluence requires TomCat as its webserver it had to run on a separate port to Apache. This meant several people couldn’t view it in their organisations.

Sounds to me like a case of bad platform choice. Now, I am by far not as technically inclined as Tom is, and am biased: I won’t touch anything that needs to be installed. That’s what Software as a Service is for. Which, incidentally is an available option for Confluence, so how Tom got into comparing “hard-to-install” Confluence with hosted PBwiki and Socialtext is beyond me – it’s an apples-to-oranges comparison. And there’s not much of a comparison either… here’s all he has to say about two other products:

By the way, I did also try out DekiWiki and Twiki but I ruled them out quite early on.

That’s not a very detailed review, if you ask me. DekiWiki is downloaded about 3000 times a day (!), so some people must like it… even though their acquisition of SocialText was just an April 1 joke. smile_regular

Joke apart, a word on picking the right tool for the right job: perhaps you don’t even need an “enterprise class” wiki for a conference. The official Oracle Wiki is based on Wetpaint, a decidedly consumer and community-focused platform.

My personal takeaway from this to me is to look at PBWiki: when I last checked it out, it was a baby-wiki for some reason popular in geek circles; apparently it has grown up. I’m not sure I will get to do the wiki review I’ve been planning, but in the meantime if Tom decides to write a real one, I am looking forward to reading it.

Update: Tom responded in a comment below. The hosted version of Confluence is NOT available under the community license. He ruled out DekiWiki as when he figured he could not to create Groups. There’s more, please read his comment.

post

Enterprise Software: from ERP to BRP

I had already spent half a decade implementing SAP solutions in the 90’s when I finally got enlightened, learning the “proper term” for what I was doing: ERP, as in Enterprise Resource Planning. The term was coined by then Gartner Analyst, now Enterprise Irregular Erik Keller. Now another fellow Enterprise Irregular, Sig Rinde introduces a new interpretation of ERP: Easily Repeatable Process. Of course he contrasts that with his new acronym, BRP (not to be confused with BPR, another 90’s favorite), which means Barely Repeatable Process. BRP is what Thingamy, Sig’s lightweight, extremely adoptable system attempts to address. But it’s a very-very tough sell…

ERP traditionally addresses the core, standard, and as such repeatable business processes. Whatever it can’t handle are the exceptions: processes to be handled by knowledge workers outside the realm of ERP, by traditional means: phone calls, spreadsheets, creative thinking and a lot of emailing back and forth. Exceptions may be a fraction of business volume, but they are what corporate employees spend most of their time resolving. If that’s the case, knowledge workers who come up with innovative solutions may consider it a good practice to document them just in case the “exception” ever occurs again… and if it does a few times, well then it’s no longer an exception, but a (Barely) Repeatable Process.

Wikis in the Enterprise are a simple yet effective solution to manage such BRPs: they facilitate collaboration of all knowledge workers involved, allow some structure (structure is helpful when not pre-imposed but flexibly created) to organize data and finally, as a by-product they serve as documentation of the solution for future re-use.

Neither process-driven heavyweight systems like ERP, nor innovative, lightweight collaboration tools like wikis are the one and only mantra for most businesses (see my previous rant on “you can’t run your supply chain on a wiki“), they have their own place and should complement each other. Standard business processes and exceptions are not black-and-white opposites either: it’s a continuum, and halfway is BRP. If ERP (in the traditional meaning) tries to address to many of theses BRPs, it gets overly complex (it already is!), hard to configure and use.

This is the dilemma Sig’s system, Thingamy addresses. It’s neither free-form collaboration, nor ERP: it’s a business system framework, that allows you to model and define business processes: a tool to create your own custom-made ERP, if you like.

And therein lies the rub. Most business users don’t want to create software. They want to use it. This was the problem that caused the demise of Teqlo: the unfunded, unproven belief, that users actually want to interactively create their tools. No, they want to deal with the urgent business problems (the BRP), using whatever tools are readily available.

Thingamy’s dilemma is finding the customer: it certainly won’t be the business user. A modeling tool, simple it may be has a learning curve, dealing with it is a distraction to say the least. Thingamy’s likely “owner” would be corporate IT which would have to create processes on demand. But we all know what happens if you need to call IT to create a “program” for you.smile_omg Thingamy could possibly be a handy tool for consultants, system integrator firms – but they all have their own army of programmers, toolsets..etc, which makes it an awfully hard sell, IMHO.

Thingamy is no doubt an elegant solution, I just don’t see the mass market need for it, because it does not solve a mass market problem. Or I should say, it does, but there’s a mismatch between whose problems it solves and who can use it. Sig himself defines collaboration as a workaround for the Barely Repeatable Processes in the Enterprise: my bet is that this “workaround” is here to stay for a long time.

Update (3/18): CIO Magazine interviews Ross Mayfield, Founder and Chairman of Socialtext, an enterprise wiki company:

Most employees don’t spend their time executing business process. That’s a myth. They spend most of their time handling exceptions to business process.

… the greatest source of sustainable innovation is how you’re handling these exceptions to business process.

… So I’ve always looked at it as we’re doing the other half of enterprise software: making this unstructured information transparent.

post

JotSpot Born Again as Google Sites, the Wiki-less Wiki.

Three weeks ago I speculated that JotSpot, the user-friendly wiki swallowed by Google a year and a half ago would soon come out of hibernation, and Voila! here it is, rebranded as Google Sites. It is the first service only available as part of Google Apps (including the free version), although I had some difficulty accessing it. Under “Manage this Domain” I could add “Sites” as a new service, but it did not show up on my account as an accessible application. When I typed sites.google.com it wanted me to sign up for Google Apps even though I was already logged in to my account. Of course trying to do so resulted in the error message:

Google Apps for zoliblog.com has already been registered by your domain administrator. Please contact your admin directly to get access to Google Apps services.

Catch 22. But there’s a solution: just type the direct URL (sites.google.com/a/yourdomain.com as default, or customize it to your liking) and you can get into Sites. I’m sure Google will soon add it to the Apps menu. (Sidenote: my old JotSpot account is still alive at name.jot.com).

Google no longer calls this a wiki, which I think is a good move. I previously wrote:

Wikis have arrived when …you don’t even have to know what they are to use one. You don’t have to know you’re using a wiki, just happily type away, creating shareable content on the Web.

I was discussing Wetpaint, the user friendly, wiki-less wiki there, and I think it’s smart of Google to follow that pattern… more later, but first, under the hood it is still a wiki, so let’s examine some of the wiki basics.

The interface is familiar from good old JotSpot (as a sidenote, the old JotSpot accounts are still alive at name.jot.com). There’s a basic wysiwyg editor, the Edit button is large and visible, and so is the New Page button. Good old JotSpot had several more ways of creating new pages, which are gone – perhaps for the best:

  • WikiWords or CamelCase: in old JotSpot anything you typed with embedded capitalization became a link to a page. As a relatively early wiki-user I liked it, as the easiest way to LinkAsYouThink. But in the Web 2.0 age we keep on bastardizing grammar writing EveryThingLikeThis, so more and more WikiWords had to be “unlinked”… too much confusion, especially for the new generation of mainstream users.
  • Linking to a shell-page before it’s created. This was a useful feature, even if we eliminate camelcase, I could use the “Link” icon, and mark up text as a link to a new sub-page, to be filled with content later. Again, this supports flow-thinking, or LinkAsYouThink, which I regret is gone.
  • The “New Page” button. This is the only remaining option in Google Sites, and I think the fact that it offers to pick a parent page (enforced hierarchy) is an improvement. No more orphan pages, yet relatively flexible hierarchy.

For those not too familiar with wiki terms, I discuss some of these concepts in more detail here: technically an article on SocialText 2.0, but I often make comparisons to JotSpot and Atlassian’s Confluence.

I’m glad to see Sites retained breadcrumbs for easier navigation, and they added sitemaps, a tree-style view of all your pages. This could be improved to allow for drag-and-drop style moving of the pages (changing the hierarchy), like Zoho Wiki does.

I’m surprised Sites still does not have inbound links: this is a critical feature for all wikis, whatever we call them. A wiki is all about associating pieces of information with each other, and the inbound link, also referred to as backlink shows you where the information on the current page is used elsewhere. The JotSpot tea half-recognized the importance of backlinks, as they were available as as a downloadable plugin on the Jot Development wiki, but never made it to the standard feature-set, and are apparently lost in the Google reincarnation, at least for now.

Attachment handling is as good as it was in the original JotSpot: it maintains previous versions, allows users to revert to earlier ones…etc. However, Google missed a huge chance here to by not offering to convert the attached documents to its own Google Docs style. This point takes us to the next level: stepping outside the boundaries of a standalone wiki and using it as a facility to pull together data created by other applications.

Last year I said after burying JotSpot for a year, Google can’t just release it as a wiki, instead:

…I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

  • It could provide for much better document management than the current Docs &­ Spreadsheets UI.
  • It overlaps with Page Creator, also with the simplified version found in Google Groups – in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
  • Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.

Well, what’s the score on that prediction? Google Sites is a better replacement for Page Creator, Google ditched the JotSpot “apps”, replacing them with their own ones – so far 2 scores out of 3. As for document management.. well, I’d say half a score, or less. (Hey, that’s 2.5 out of 3smile_tongue)

You can somewhat integrate Google Docs (which includes documents, spreadsheets and presentations) by embedding them into any Google Sites page. You have to enter the specific URL though – why not just select from a list? Furthermore, your Google docs or spreadsheets have to be first made public and you have to use the public URL to embed them into Sites. Here’s my test site, showing first an error message, then the actual embedded spreadsheet, after I made it public.

The embedded docs appear properly in the saved page, but I can’t click on it, not even in Edit mode to get to the source. In fact in Edit mode all I see is a graphical placeholder for the embedded doc.

How about sharing / collaboration? As expected, your Sites can be:

  • private
  • public
  • shared with individual email id’s
  • shared with everyone within your domain

…and you can set view or edit options for all those levels. However, Google missed a big chance again. As a complete coincidence, it’s only yesterday that I raved about Zoho’s Group level sharing, half-announced in a fairly understated manner – hidden in a list of Zoho Writer enhancements. Well, Google already has a very good group facility: Google Groups, which started it’s life as a group discussion / forum system, but it gradually evolved into a decent collaboration platform. Once I have a “group” defined (i.e. the list of members), why doesn’t it become an entity I can share my wiki (sites) or docs with? When I invite users to share the wiki with, there’s an option to save the list as group, but I don’t know where it disappears, can not pull it up either within the wiki or gmail, or docs.

Finally there are gadgets, but if you read Dennis Howlett at ZDNet, gadgets might the feature you don’t want to touch with a ten-foot pole. smile_sad

Summary: Nice to have Jot back (even if we did not get GSpot.smile_embaressed ) Google now has a pretty good and easy web-page creator with some wiki features made user-friendly, and a half-hearted attempt at integrating the rest of the Apps empire using Sites. Perhaps they get it right in the next release.

Related posts: TechCrunch, eWeek, Ross Mayfield’s Weblog, Irregular Enterprise, Mashable!, InfoWorld, Between the Lines, Portals and KM, CNet, Webware, GigaOM, Web Worker Daily, Venture Chronicles, Insider Chatter, Learning and Technology, Solo Technology.

post

Is GSpot (Google + JotSpot) Release Imminent?

This is a speculative post.   As it is widely known, JotSpot, a very user-friendly wiki and application-platform-wannabe was acquired by Google in October 2006, only to be closed for new users for a long time. Existing users could continue to access their information free.

There was a lot of speculation as to when it would re-surface and in what shape.  I certainly liked the wiki before they “disappeared”, and was hoping The Goog would take the opportunity to do more than just re-label it and make it more scalable:

I hope that means they rethought everything and integrated JotSpot well into a number of offerings.

  • It could provide for much better document management than the current Docs &­ Spreadsheets UI. 
  • It overlaps with Page Creator, also with the simplified version found in Google Groups – in fact Groups which is no longer just email lists but a rudimentary collaboration platform and JotSpot could very well be merged / integrated.
  • Finally JotSpot tried to provide primitive applications (spreadsheet, calendar..etc) all of which have a better Google counterpart, so one would hope they will be replaced, too.

Perhaps we’re getting close to the re-emergence of JotSpot (yes, I know it won’t be called GSpot, but why not have some fun?). Obviously this is the speculative part, but several users report that JotSpot wikis disappear from the net.  Users are understandably getting excited:

Is it over? Just like this? Without notice?

I just finished a major rework on the site. And 4 hours after it:
boom, it disappeared.

Any help?
Where is all the data gone?

The main jot.com page displays a Network Solutions domain capture page. 

I can still access www.jot.com, which displays the standard notification about the Google transaction, and, more importantly I can get into my jot account using the direct URL:  account.jot.com.  I am using OpenDNS.  Perhaps the difference is a matter of DNS propagation, and they are changing in preparation of the Google Wiki launch?

My previous coverage:

(Hat tip: Isaac Garcia, CEO of Central Desktop)

Update (2/6):  Mashable list 14 of what they call Online Spreadsheet Applications (clearly, not all are) and surprise, surprise, JotSpot is one of them.  That’s a joke. As much as Iiked JotSpot as a wiki, it failed to become an application platform, and it certainly isn’t (hasn’t been) a spreadsheet.  Like I wrote before:

Just because a page looks like an application, it does not mean it really is. Try to import an Excel spreadsheet into a Jot Spreadsheet page, you’ll get a warning that it does not import formulas. Well, I’m sorry, but what else is there in a spreadsheet but formulas? The previous name, Tracker was fair: it’s a table where you track lists, but not a spreadsheet. (more)

But whatever we think of the former JotSpot Tracker capabilities, it’s hard to see it left intact once Google releases what they turned JotSpot into.   Google themselves have a much better online spreadsheet, I certainly hope for their sake that they will integrate their apps with JotSpot, and kill off the overlap.

(FYI: The real online spreadsheets out of Mashable’s 14 are Google , Zoho, EditGrid, ThinkFree.  )

post

Can the Software Sector be Resilient to Recession?

I was very lucky in the early 90’s being in an industry that was not only shielded from recession, in fact it was thriving.  Corporate America was taught to fight their way out of the slump by Business Process Reengineering, and what better way to execute it than by implementing new integrated business information systems.  The slump for the rest of the country was a major boom for SAP, and the entire ERP industry born in their footsteps.

Today we’re amidst another technology change, one that may just ensure relatively smooth sailing through a recession for the Software sector – at least those who are on the right side of the change.smile_wink  The belts will be tightened, says the New York Times, but technology will still grow, just at a slower rate:

Overall growth in technology spending may fall from 7 percent last year to 4 percent or less this year, according to estimates by IDC, a research firm.

But that won’t be nice 4% growth for the entire industry; I strongly believe pioneers of Software as a Service (SaaS) will be amongst coming out of a slow-down as winners, leaving others in the dust. 

TechCrunch is optimistic for the entire Web 2.0 business:

All of those Enterprise 2.0 startups out there, or even Amazon trying to sell Web-based computing infrastructure, are actually at an advantage. Customers are more likely to try cheap cloud computing when they can no longer afford the alternatives.

ZDNet’s Dan Farber disagrees:

Most of the Web/Enterprise 2.0 startups can’t get a hearing with CIOs and tech buyers at corporations. While consumer applications are influencing corporate applications and coming in through the back door, Enterprise 2.0 apps (blogs, wikis, predictions markets, social networking, mashups, collaborative cloud-based apps and technologies such as RSS and tags) are just beginning to reach the radar of larger corporations, and they are not considered mission critical, which is where the money is funneled first

I think they are both right – and wrong.  I don’t agree that the entire Web 2.0 sector is immune to a down-turn: the advertising market will shrink,  the “lets-grow-insanely-who-needs-a-business-model” types will suffer. As Software VC Will Price says:

It may well be that Slide raising $55m from mutual fund companies at $500m+ pre-money will be the “what were we thinking” moment of the current cycle.

I also agree with Will, that a movie we’ve all seen will be playing again:

The last downturn saw the valley swing violently away from consumers to the enterprise – bastions of value, hard ROI, tangible value propositions, enterprise pain points and budgets, etc became the mainstay of investment decisions and the consumer, I kid you not, was literally a bad word…
The valley became all enterprise, all the time.

It will not be all, and not only Enterprise, but Business Software, whether for the Enterprise or small businesses will come back with a classic, “old-fashioned” business model of actually charging for value (product or service) delivered.  Of course there is still the dilemma of selling business software – much better if you don’t have to, it is getting bought instead. smile_shades  Yes, Dan is right, “Web/Enterprise 2.0 startups can’t get a hearing with CIOs and tech buyers at corporations” and their  apps are not considered mission critical, but the whole point is that a lot of these Enterprise 2.0 tools are not sold at the CIO level.

The after-bubble nuclear period of “no IT spending at all” found me at a startup. We did not exactly hit it big, but did not go under, either, and that’s because our model allowed us to get in the door way below the threshold that would have required higher authorization. Not classic SaaS, rather SES (Software Enabled Service), we were essentially data providers and often got into an “enterprise” account at $3k for the first month … ramping up to $60-$100K annually.   Anyone familiar with Enterprise Sales knows the term Economic Buyer:  typically getting involved later at the sales cycle, approving or nuking the deal.  Well, we saw no Economic Buyer: being under the threshold, we sold to the User directly.

As Zoho CEO Sridhar Vembu adds to the discussion:

It is useful to remember that both Salesforce & WebEx thrived during the last recession – in fact they were relatively unknown during the last boom. Cost was a major part of the reason they thrived in the bust.

Indeed. Software as a Service and the typically associated pay-as-you-go model allows businesses – enterprise and SMB – to use software without the typical upfront investment the traditional model would require, therefore SaaS providers have a good chance of withering a Recession.  Another noteworthy idea in Sridhar’s response is that they really don’t have to have a “massive win”, a total move from the desktop to the cloud: a “marginal” business  is good enough.

Of course this “marginal business” is not as attractive to many startup entrepreneurs as fast forwarding to the IPO, preferably over $1.5B. In fact it’s really boring… building a business gradually; no IPO thrill; serving millions of customers, helping them actually conduct business.  Oh, and making millions of dollars of real revenue in the process – not bad, if you ask me.  And it’s quite bubble-proof. smile_wink

Related posts: Vinnie Mirchandani –  Why it will be very different this time, Fred Wilson- This Time Will Be Different.

Update (1/28): Forrester Research predicts gains for Enterprise Web 2.0 apps in 2008.   Also read: Between the Lines, ReadWriteWeb.