Another Word For It

Atlassian’s Causium Sales Model Reaches $2.5 Million Charity Donations by Kit Eaton.

From the post:

Back in May 2010 Atlassian, a large innovative software company, revealed that its alternative business model causium had allowed it to donate $500,000 to international literacy improvement charity Room to Read. Now the firm says it has surpassed $2.5 million in donations, and is holding a special event with the charity on May 14th to celebrate.

Causium is an alternative to the freemium business model that many companies–from the Wall Street Journal to Babbel–follow. Under freemium thinking, Atlassian would give away some of its enterprise-grade code for free in order to attract business for its paid services. But instead, the company charges a nominal $10 fee, which it then donates to charity. The fee works in two ways–as a boost to charitable causes, and also to demonstrate to the software’s end-users that the code itself has value.

Atlassian’s President Jay Simons spoke to Fast Company, explaining that the plan has worked better than they expected: “We didn’t appreciate at the time that we were effectively building this annuity stream. Customers that buy the 10-user license will buy it again the following year.” The first year of the plan resulted in some $300,000 in charity donations, and the growth of the company’s reputation since means they donated the same amount in the first quarter of 2013. The donations are important to Room to Read, Simons says, because “they have a reliable funding source” on a regular basis.

Important to note that Atlassian had the market presence to make a causium sales model work.

On that score, see:

Why Atlassian is to Software as Apple is to Design by Mark Fidelman.

and, of course:

Atlassian.

Important lessons if you hope to make your software or service a success.

How to Go Viral, Every Time by Jess Bachman.

From the post:

Everyone wants their content to go viral. It’s the holy grail of marketing. It can turn companies and product into the talk of the town, even if they sell toiletries. The ROI on content with more than a million views is almost unmeasurable. So how do you make sure your content will go viral?

The secret is simple. Be incredibly lucky.

Luck is the third piece of the virality triumvirate and obviously the hardest to bank on. In fact, you cannot achieve true virality without it. With great content and powerful tactics you can certainly get millions of views on a consistent basis, but if lady luck doesn’t give her blessing, you will end up with a good – but not great – ROI.

What do you think would make good viral material for a topic map video?

And of course:

Anyone with skills at producing videos interested in a topic map video?

HowTo: Develop Your First Google Glass App [Glassware] by Tarandeep Singh.

From the post:

Google has raised curtains off it’s Glass revealing detailed Tech Specs. Along with the specs came the much awaited Mirror API – The API for Glass apps.

So you had that killer app idea for Google Glass? Now its time for you to put those ideas into code!

The race is on to produce the first topic map based Google Glass App!

A response to a request can be a machine generated guess or a human curated answer.

Which one do you think users would prefer?

If you haven’t seen Glass, go to: http://www.google.com/glass/start/

If lame search results are annoying on your desktop, pad or cellphone, imagine not being able to escape them.

Of for a positive spin, would you want a service provider with better results?

Bad data “in your face” may be the selling point we need.

Dylan Jones writes in Data Quality: One Habit at a Time:

I started learning about data quality management back in 1992. Back then there were no conferences, limited publications and if you received an email via the internet the excitement lasted for hours.

Fast forward to today. We are practically swamped with data quality knowledge outlets. Sites like the Data Roundtable, OCDQ Blog and scores of other data quality bloggers provide practical ideas and techniques on an almost hourly basis.

We never lack for ideas and methods for implementing data quality management, and of course this is hugely beneficial for professionals looking to mature data quality in their organisation.

However, with all this knowledge comes a warning. Data quality management can only succeed when behaviours are changed, but to change a person’s behaviour requires the formation of new habits. This is where many projects will ultimately fail.

Have you ever started the New Year with a promise to change your ways and introduce new habits? Perhaps the guilt of festive excesses drove you to join a gym or undertake some other new health regime. How was that health drive looking in March? How about September?

The problem of habit formation is exacerbated when we attempt to change multiple habits. Perhaps we want to combine a regular running regime with learning new skills. The result is often failure.

Does your topic maps sales pitch require too much change? (I know mine does.)

Or do you focus on the one issue/problem that your client needs solving?

Sure, topic maps enable robust integration of diverse data stores but it that’s not your clients issue, why bring it up?

Can we sell more by promising less?

Most topic map software, either explicitly or implicitly, is targeted at developers.

I ran across a graphic today that highlights what I consider to be a flaw in that strategy.

The original graphic concerns the number of students enrolled in computer science:

I first saw that in a tweet by Matt Asay.

I need to practice (read learn) Gimp skills so my first attempt to re-purpose the graphic was:

But that leaves my main point implied, so after some fiddling, I got:

Even without a marketing degree, I can pick the better marketing target.

What about you?

BTW, the experience with Hadoop supports my side, not the targeting for developers argument.

Yes, a lot of Hadoop tools are difficult to use, if not black arts.

However, Hadoop marketing has more hand waving and arm flapping than you will see among Democrats on entitlement reform and Republicans on tax reform, combined.

The Hadoop ecosystem (which I like a lot by the way) is billed to consumers as curing everything but AIDS and that is just a matter of application.

Consumer demand, from people who aren’t going to run Hadoop clusters, write pig scripts, etc. is driving developers to build better tools and to learn the harder ones.

Suggestions on how to build consumer oriented marketing of topic maps will be greatly appreciated!

You may already be aware of threats and legal proceedings by Edwin Mellen Press against criticism of itself and its publications.

For one recent update, see: Posts Removed Because We’ve Received Letters From Edwin Mellen Press’ Attorney by Kent Anderson.

For further background, see: When Sellers and Buyers Disagree — Edwin Mellen Press vs. a Critical Librarian by Rick Anderson.

The thought occurs to me that over the years there must be a treasure trove of letters and other communications from Edwin Mellen Press, not to mention litigation files, depositions, etc.

But any story about Edwin Mellen Press will be written with access to only part of that historical information.

What if McMaster University were to publicize the “…demands and considerable pressure from the Edwin Mellen Press….?” And those demands could be mapped to other demands against others?

The demands by Edwin Mellen Press have been made against librarians. The very people who excel at the collection and creation of archives.

Is it time for the library community to pool its knowledge about Edwin Mellen Press?

My time resources are limited but I would be willing to contribute as I am able to such an effort.

You?

On the eight day of creation [language and time units are for the convenience of the reader. The celestial court exists outside of their strictures].

I started this post off as an April Fools Day gag but the keyboard ran away from me.

See what you think.

L = Lord

O = Other member(s) of the celestial court

L: The Tower of Babel is another example of bad PR from my own followers.

O: How so? Didn’t you confuse their languages to prevent an assault on Heaven?

L: Look around you. It is likely I would be fearful of someone piling up bricks to assault Heaven?

O: Well, now that you mention it, no, it doesn’t seem likely. (In an uncertain tone of voice.)

L: Would it help if I explained why humans invented the story of the Tower of Babel?

O: Nodding quickly.

L: Arrogance.

O: Arrogance?

L: Think about it. There are two types of people. One type thinks they know what and how everyone else should be thinking. The other type knows who should be telling others what and how to think.

The Tower of Babel story blames me for the competition to force others to a single way of thinking.

What’s ironic is their arrogance multiplies the number of languages and approaches to languages. Every generation denigrates what went before, for a new bumper crop of shiny “truths.”

Need an example?

Take their “when in the beginning there was FORTRAN….”

Now look at any listing of major programming languages, never mind the smaller ones.

No Tower of Babel story there.

O: What about the Tower of Babel as an explanation for different languages?

L: Glad you asked.

I’ll give you one guess who thinks they are entitled to an explanation for everything.

More listening to others and less whining about not being in charge would be a start towards less confusion of languages.

The Telenor post reminded me about my arguments about topic maps saving users time by not (re)searching for information already found.

In Telenor’s case, there was someone, customers in fact, who wanted faster and more accurate information.

Is there a business case for avoiding (re)searching for information already found?

Say where research is being billed to a client by the hour?

The more attorneys, CPAs, paralegals, etc. that find the same information = more billable hours.

Where a topic map = fewer billable hours.

And where billable hours aren’t an issue, what do users do with the time they used to spend on the appearance of working by searching?

I am reminded of a then department manager who described themselves as “…doing market research…” by reading the latest issue of Computer Shopper. Nearly twenty (20) years ago now but even then there were more effective means of such research.

On the other hand, there may be cases where use of topic maps by one side may force others to improve their game.

Intelligence gathering and processing for example.

Topic maps need not disrupt current layers of contracting, feathered nests and revolving doors, to say nothing of the turf guardians.

But topic maps could envelope such systems, in place, to provide access to integrated inter-agency intelligence, long before agreement is reached (if ever) on what intelligence to share.

Thinking of ways that topic maps are the same or different from other information technologies.

Your Data: I think all information technologies would claim to handle your data. Some focus more on structured data that others but in general, all handle “your data.”

Your Model: This is where topic maps and key/value stores depart from the Semantic Web.

You don’t get “your model” with the Semantic Web, you get a prefab logical model.

Contrast that with topic map where you can have FOL (first order logic), SOL (second order logic) or any other logic or non-logic you choose to have. It’s your model and it operates as you think it should. Could even be: “go ask Steve” for some operations.

The Semantic Web types will protest not using their model means your data won’t work with their software. Which is one of their main reasons for touting their model. It works with their software.

Personally I prefer models that fit my use cases. As opposed to models whose first requirement is to work on a particular class of software.

Guess it depends on whether you want to further the well being of Semantic Web software developers or your own.

Your Vocabulary: Another point where topic maps and key/value stores depart from the Semantic Web.

The vocabulary you choose for your model is your own.

Which is very likely to be more familiar and you can apply it more accurately.

How do topic maps differ from key/value stores?

Two things come to mind. First, topic maps have inherent machinery for the representation of relationships between subjects.

Not that you could not do that with a key/value store but in some sense a key/value store is more primitive than a topic map. You would have to build up such structures for yourself.

Second, “as is,” key/value stores (at least the ones I have seen, which isn’t all of them), don’t have a well developed notion of subject identity.

That is keys and values are both treated as primitives. If your key and my key aren’t the same, then they must be different. Or if they are the same, then they must be the same thing. Same for values.

That may not be a disadvantage in some cases where information aggregation or merging isn’t a requirement. But it is becoming harder and harder to think of use cases where aggregation/merging isn’t ever going to be an issue.

I need to cover issues like the differences between topic maps and key/value stores more fully.

Would you be interested in longer pieces that could eventually form a book on topic maps?

Perhaps even by subscription?

Expectation and Data Quality by Jim Harris.

From the post:

One of my favorite recently read books is You Are Not So Smart by David McRaney. Earlier this week, the book’s chapter about expectation was excerpted as an online article on Why We Can’t Tell Good Wine From Bad, which also provided additional examples about how we can be fooled by altering our expectations.

“In one Dutch study,” McRaney explained, “participants were put in a room with posters proclaiming the awesomeness of high-definition, and were told they would be watching a new high-definition program. Afterward, the subjects said they found the sharper, more colorful television to be a superior experience to standard programming.”

No surprise there, right? After all, a high-definition television is expected to produce a high-quality image.

“What they didn’t know,” McRaney continued, “was they were actually watching a standard-definition image. The expectation of seeing a better quality image led them to believe they had. Recent research shows about 18 percent of people who own high-definition televisions are still watching standard-definition programming on the set, but think they are getting a better picture.”

I couldn’t help but wonder if establishing an expectation of delivering high-quality data could lead business users to believe that, for example, the data quality of the data warehouse met or exceeded their expectations. Could business users actually be fooled by altering their expectations about data quality? Wouldn’t their experience of using the data eventually reveal the truth?

See Jim’s post for the answer on the quality of data warehouses.

Rather than arguing the “facts” of one methodology over another, what if an opponent were using a different technique and kept winning?

Would that influence an enterprise, agency or government view of a technology?

Genuine question because a large percentage of enterprises don’t believe in routine computer security if the statistics are to be credited.

That despite being victimized by script kiddies on a regular basis.

Of course, if the opponent were a paying customer, would it really matter?

Start Presentations on the Second Slide by Kent Beck.

From the slide:

Technical presos need background but it’s not engaging. What’s a geeky presenter to do?

I’ve been coaching technical presenters lately, and a couple of concepts come up with almost all of them. I figured I’d write them down so I don’t necessarily have to explain them all the time. One is to use specifics and data. I’ll write that later. This post explains why to start your presentation on the second slide.

I stole this technique from Lawrence Block’s outstanding Telling Lies for Fun and Profit http://amzn.to/YTAf3C, a book about writing fiction. He suggests drafting a story the “natural” way, with the first chapter introducing the hero and the second getting the action going, then swapping the two chapters. Now the first chapter starts with a gun pointed at the hero’s head. By the end, he is teetering on a cliff about to jump into a crocodile-infested river. Just when the tension reaches a peak, we’re introduced to the character but we have reason to want to get to know him.

Technical presentations need to set some context and then present the problem to be solved. When presenters follow this order, though, the resulting presentation starts with information some listeners already know and other listeners don’t have any motivation to try to understand. It’s like our adventure story where we’re not interested in the color of the hero’s hair, at least not until he’s about to become a croc-snack.

Be honest. At least with yourself.

How many times have you started a topic maps (or other) technical presentation with content either known or irrelevant (at that point) to your audience?

We may be covering what we think is essential background information, but at that point, the audience has no reason to care.

Let me put it this way: explaining topic maps isn’t for our benefit. It isn’t supposed to make us look clever or industrious.

Explaining topic maps is supposed to interest other people in topic maps. And the problems they solve.

Have you tried the dramatic situation approach in a presentation? How did it work out?