Other

Free Application Showcases WebCenter Mobile Access Capabilities for Sales Enablement and Offline Content Access

Fishbowl Solutions is excited to announce the release of our Fishbowl Mobile Library Android application on the Google Play Store. This free version of Fishbowl’s Mobile Tablet Application for Oracle WebCenter Content allows customers to experience mobile WebCenter functionality first hand. By enabling mobile access to Oracle WebCenter Content, users can find, store, view, and organize content from the Oracle WebCenter repository directly on their tablets.

Features of the Fishbowl Mobile Library app include access to Oracle WebCenter Content with the ability to view content including PDFs, HTML, images, and video, as well as the option to keep local copies of content items for offline use. These copies are synced with WebCenter when reconnected. Customized Folder View options enable the user to organize local content into a personalized folder structure and the Content Sharing feature provides the option to add items to an email cart which emails links to download items from a secure temporary download site.

The Android application is built on Fishbowl’s Mobility API and serves as a reference for mobile applications integrated with Oracle WebCenter Content. This mobile content library application framework is currently in production on both Android Tablets and the Apple iPad.

To learn more about the Fishbowl Mobile Library app, please visit our Fishbowl Solutions Mobile Tablet App Page or download the app from the Google Play Store.

The app is also available for iPad from the iTunes Store download the free Fishbowl ECM Mobile App Download on iTunes.

The post “Fishbowl Mobile Library” Android Tablet App Now Available on Google Play appeared first on C4 Blog by Fishbowl Solutions.

From time to time I advise a software vendor on how, whether, or to what extent it should offer its technology in open source. In summary, I believe:

• The formal differences between “open source” and “closed source” strategies are of secondary importance.
• The attitudinal and emotional differences between “open source” and “closed source” approaches can be large.
• A pure closed source strategy can make sense.
• A closed source strategy with important open source aspects can make sense.
• A pure open source strategy will only rarely win.

Here’s why.

An “open source software” business model and strategy might include:

• Software given away for free.
• Demand generation to encourage people to use the free version of the software.
• Subscription pricing for additional proprietary software and support.
• Direct sales, and further marketing, to encourage users of the free stuff to upgrade to a paid version.

A “closed source software” business model and strategy might include:

• Demand generation.
• Free-download versions of the software.
• Subscription pricing for software (increasingly common) and support (always).
• Direct sales, and associated marketing.

Those look pretty similar to me.

Of course, there can still be differences between open and closed source. In particular:

• Open source can help with sales to enterprises that don’t trust a new vendor to keep progressing.
• Open source can hurt with sales to enterprises that jump at the opportunity to do what they want, themselves, for “free” and — which in some cases is important to them — in secret.
• Open source has fewer pricing option than closed.

Summing up the story so far, then, closed source is a superior strategy to open, except and to the extent that your are forced down the open route. More precisely, any advantages to an open source strategy can also be captured by having a hybrid open/closed strategy that emphasizes the closed part.

So what part of the story haven’t I told yet? Mainly, it’s open source marketing. Open source can seem virtuous and/or cool — to users, influencers, or even your own engineers. But while that’s true of people, it’s less true of companies, which are unlikely to spend a lot of money on the basis of coolness or virtue. Rather, the strictest believers in acquiring open source software do so precisely because it’s something for which they don’t have to pay, or pay much.

Further, some people think pro bono is a business strategy, because if you build up enough users, monetization can eventually follow. In the cases of more-or-less explicit advertising, pro bono really does work. I give away the content of this blog; in return, people contact me from time to time and offer to buy my services — with “sales cycles” so short as to be unworthy of the name. Fun ensues, and profit. The connection is even clearer in the case of traditional mass media, or of internet services such as Twitter and Facebook. But when what you’re selling and giving away are both technology, the pro bono story has to be something like “We’ll get you hooked on the free stuff, then charge you for the rest.”

That may be great for games, but how does it work for professional software? There are some special cases, mainly:

• Your product can be used by awesomely impressive internet companies that, while refusing to pay for software themselves, validate it for adoption by lesser organizations that indeed are willing to pay. This has worked for multiple projects started by those companies themselves, such as Hadoop and memcached, but only one I think of that wasn’t — MySQL.
• You can let users gain attachment to your free stuff, then sell your whole company to somebody who now wants to sell them other stuff, presumably closed source (or hardware), or who just is impressed by the awesomeness of your technology. This strategy has produced a very small number of great exits — XenSource, arguably Nicira (although Nicira itself disagrees), maybe a couple of others.

But in most cases, the strategy loops back what I described at the top of this post:

• A free core product, which may be genuinely valuable to some/most users, and which certainly offers them a great opportunity to test the technology, plus …
• … a chargeable/proprietary add-on, which is required for the most serious work, …
• … or else just support.

There aren’t actually a lot of major examples in the “just support” camp* — the main ones who come to mind are Red Hat, 10gen, and Hortonworks, and two of those three are for products that were open source projects long before the respective companies were founded. And so we’re right back to an Enterprise Edition/Community Edition split.

*Or “mainly just support” — as per my recent post on Hadoop distributions, almost everybody offers SOMETHING proprietary.

This all still leaves an attitudinal distinction among (in decreasing order of open source rah-rah virtue):

1. Build and promote a great free product. One of these years, get around to building and promoting a great chargeable one as well.
2. Build and promote both a great free product and a great chargeable one.
3. Build and promote a great chargeable product, and give a subset of it away for free. That subset should be good too.
4. Build and promote a great chargeable product, and give a crappy subset away for free.

I think #3 makes the most sense. #4 is bad because I don’t believe in promoting or distributing crappy products even for free. #2 is too big a challenge to tackle, in technology and marketing alike. And #1 is only for the most patient vendors with the deepest of pockets.

There’s also the possibility of open sourcing software and then making your main revenue from being the best hosting company for it. But to date that has worked mainly for Automattic.

Finally — what about open source as a development strategy? Well, there are indeed some projects with multiple sets of major contributors — Linux, R, Hadoop, Postgres and so on. But for projects that originate with a single sponsoring vendor, my general observation still stands:

• Open source software commonly gets community contributions for connectors, adapters, and (national) language translations.
• But useful contributions in other areas are much rarer.

Related links

• The open/closed source distinction is central to only a few of the issues on our strategy and execution worksheets, mainly the ones influenced by pricing. However, it is at least slightly relevant to a considerable fraction of them.
• I glossed over the free-like-speech/free-like-beer distinction a bit; hopefully my usage was clear in context.

Elephants! Elephants!
One elephant went out to play
Sat on a spider’s web one day.
They had such enormous fun
Called for another elephant to come.

Elephants! Elephants!
Two elephants went out to play
Sat on a spider’s web one day.
They had such enormous fun
Called for another elephant to come.

Elephants! Elephants!
Three elephants went out to play
Etc.

–  Popular children’s song

It’s Strata week, with much Hadoop news, some of which I’ve been briefed on and some of which I haven’t. Rather than delve into fine competitive details, let’s step back and consider some generalities. First, about Hadoop distributions and distro providers:

• Conceptually, the starting point for a “Hadoop distribution” is some version of Apache Hadoop.
  • Hortonworks is still focused on Hadoop 1 (without YARN and so on), because that’s what’s regarded as production-ready. But Hortonworks does like HCatalog.
  • Cloudera straddles Hadoop 1 and Hadoop 2, shipping aspects of Hadoop 2 but not recommending them for production use.
  • Some of the newer distros seem to be based on Hadoop 2, if the markitecture slides are to be believed.
• Optionally, the version numbers of different parts of Hadoop in a distribution could be a little mismatched, if the distro provider takes responsibility for testing them together.
  • Cloudera seems more willing to do that than Hortonworks.
• Different distro providers may choose different sets of Apache Hadoop subprojects to include.
  • Cloudera seems particularly expansive in what it is apt to include. Perhaps not coincidentally, Cloudera folks started various Hadoop subprojects.
• Optionally, distro providers’ additional proprietary code can be included, to be used either in addition to or instead of Apache Hadoop code. (In the latter case, marketing can then ensue about whether this is REALLY a Hadoop distribution.)
  • Hortonworks markets from a “more open source than thou” stance, even though:
    • It is not a purist in that regard.
    • That marketing message is often communicated by Hortonworks’ very closed-source partners.
  • Several distro providers, notably Cloudera, offer management suites as a big part of their proprietary value-add. Hortonworks, however, is focused on making open-source Ambari into a competitive management tool.
  • Performance is another big area for proprietary code, especially from vendors who look at HDFS (Hadoop Distributed File System) and believe they can improve on it.
  • I conjecture packaging/installation code is often proprietary, but that’s a minor issue that doesn’t get mentioned much.
• Optionally, third parties’ code can be provided, open or closed source as the case may be.

Most of the same observations could apply to Hadoop appliance vendors.

Besides code, Hadoop distribution providers commonly offer support. The Hadoop support situation is confused, largely because:

• Marketing around Hadoop support capabilities and experience is sparse …
• … except for the Hortonworks vs. Cloudera General Hadoop Expertise Urinary Olympics.
• I don’t hear a lot of complaints about anybody’s Hadoop support.

That said:

• One should distinguish between, say, Tier 1 and Tier 3 support.
• Since most serious Hadoop development is done by Cloudera and Hortonworks, those two vendors are by far the best qualified to do Tier 3+ support.
• Since Cloudera has the most Hadoop market share to date, it also has the most Hadoop support experience (any and all tiers).
• Some of the other contenders are huge companies that presumably know how to support enterprise customers. This includes both distro providers and others (e.g. Oracle, which sells a Cloudera-based appliance and handles Tier 1 support for that itself).

And finally, reasons that come to mind for choosing particular distributions include:

• Cloudera
  • Cloudera Manager is (relatively speaking) mature.
  • Cloudera Navigator seems promising.
  • Cloudera has the most experienced Hadoop services operation.
  • Cloudera has the development “axe” in some parts of Hadoop and is second only to Hortonworks in the others.
  • Cloudera has lots of partner support.
  • Cloudera is the best-funded company whose main business is Hadoop.
• Hortonworks
  • With the arguable exception of Cloudera, Hortonworks has much more Hadoop expertise than any other outfit, including the development “axe” in a variety of areas.
  • Hortonworks has lots of partner support.
  • Hortonworks is the second-best-funded company whose main business is Hadoop.
  • Because of its low reliance on proprietary code, Hortonworks has great “escapability”, and correspondingly weak pricing power vs. its customers.
• Intel
  • Intel’s Hadoop performance hacks may be legit.
  • Intel was evidently early in supporting Chinese Hadoop users.
• EMC/Pivotal/Greenplum
  • If you want to use the Greenplum DBMS, using the Pivotal/Greenplum Hadoop distribution too would seem to be thematic.
• MapR
  • At one point MapR seemed to have a performance advantage. I don’t know whether that’s still the case.
• IBM
  • Some believe that IBM removes obstacles, and grants blessings of prosperity and wisdom.

My former friends at Greenplum no longer talk to me, so in particular I wasn’t briefed on Pivotal HD and Greenplum HAWQ. Pivotal HD seems to be yet another Hadoop distribution, with the idea that you use Greenplum’s management tools. Greenplum HAWQ seems to be Greenplum tied to HDFS.

The basic idea seems to be much like what I mentioned a few days ago  — the low-level file store for Greenplum can now be something else one has heard of before, namely HDFS (Hadoop Distributed File System, which is also an option for, say, NuoDB). Beyond that, two interesting quotes in a Greenplum blog post are:

When a query starts up, the data is loaded out of HDFS and into the HAWQ execution engine.

and

In addition, it has native support for HBase, supporting HBase predicate pushdown, hive[sic] connectivity, and offering a ton of intelligent features to retrieve HBase data.

The first sounds like the invisible loading that Daniel Abadi wrote about last September on Hadapt’s blog. (Edit: Actually, see Daniel’s comment below.) The second sounds like a good idea that, again, would also be a natural direction for vendors such as Hadapt.