Assuming that there’s a calabash.sh somewhere on your system, a sample invocation looks like this:

calabash.sh \
  -i source=bits.xml \
  -o qb=query_batch.xml \
  crossref/xpl/jats-submit-crossref-query.xpl \
  email=X@Y \
  user=USER pass=PASS \
  xpath='(//sec)[last()]'

It takes some BITS/JATS/HoBoTS XML on the source port, and it needs your CrossRef credentials and a return email address where the resolved XML will be sent to after batch processing.

If you want to restrict the query to only some citations in your source XML, you can supply an XPath expression. In the example above, only the ref elements below the last sec will be included in the query. In addition, only refs with an id attribute will be processed, and refs that already have a DOI (pub-id[@pub-id-type eq 'doi']) will be excluded. Currently, it will only process mixed-citations.

There is a JATS-specific part (.xpl, .xsl) for generating a CrossRef Query Input 2.0 compliant query body, and there is a generic part for wrapping this, together with the return email address and a generated batch ID, in a query_batch element, validating it against the XSD, wrapping it, together with the credentials, in a POST p:http-request and finally submitting the query to CrossRef.

If other input formats were to be supported, it would be nice if there was only one front-end script that selects and executes the format-specific query generation pipeline dynamically, with cx:eval.

The main obstacles that had to be overcome were all related to the HTTP POST request in wrap-query.xpl:

  <p:template>
    <p:input port="template">
      <p:inline>
        <c:request 
          method="POST" 
          href="http://doi.crossref.org/servlet/deposit?operation=doQueryUpload&amp;login_id={$user}&amp;login_passwd={$pass}">
          <c:multipart content-type="multipart/form-data" boundary="=-=-=-=-=">
            <c:body content-type="application/xml" disposition='form-data; name="fname"; filename="hobots-refs.xml"'>
              {/*}
            </c:body>
          </c:multipart>
        </c:request>
      </p:inline>
    </p:input>
    <p:input port="source">
      <p:pipe step="wrap" port="result"/>
    </p:input>
    <p:input port="parameters">
      <p:pipe step="vars" port="result"/>
    </p:input>
  </p:template>
  
  <p:http-request omit-xml-declaration="false" encoding="US-ASCII"/>

In line 74, there’s a spurious GET-like URL – but it seems to work alongside the POSTed payload. This has to be in a multipart chunk, and it’s important that it has name="fname" in its Content-Disposition field. The filename is static at this point, but it’s obvious how to dynamicize it using some curly braces expression. Well, it could be difficult if there were single quotes in the expression because the whole disposition attribute is enclosed in single quotes already – I avoided this problem for the time being.

Other important attributes are the p:http-request attributes in line 91. Without omit-xml-declaration=”false”, the posted data won’t be interpreted as XML. It was hard for me to find out that this serialization option belongs to p:http-request itself, rather than p:body.

After I had successfully posted my first batch, I saw that nothing was recognized. I quickly discovered that en dashes and other “special characters” had been converted to plain question marks when sending the query batch as UTF-8. So I switched the serialization to US-ASCII, hoping that everything beyond ASCII will be transmitted as numerical entity references, and there you go.

Another problem that I discovered later: although i and b formatting is allowed in an unstructured_citation, virtually no citation would resolve. I noticed that all these formatting elements were missing in the returned, unresolved query. So they probably didn’t resolve because essential text was discarded prior to resolution. I dissolved all markup within unstructured_citation, and the results were much better.

Previously Saxon-CE was licensed on a per-site basis, but probably didn’t find many licensees yet. One reason is that mainstream Web development takes place in Javascript and that most of that stack – the browsers’ JS engines, debuggers, libraries such as jQuery, etc. – is free. When I had to outweigh the complications of Saxon CE licensing and the lack of acceptance of this maverick XSLT2 technology, even in my own organization, against the mainstram-ness of a jQuery extension, I opted for the latter.

But the idea of having XSLT2 in the browser as readily available and deployable as any jQuery extension certainly appeals to me. So I was very happy about Michael’s decision to open-source Saxon CE.

He said although he hadn’t the faintest idea how to make money off of it, it’s important to its success that Saxon CE has 1 million rather than a couple dozen users.

We find ourselves in a similar situation: After years of fumbling with ad-hoc converters and Makefile orchestrations, we’ve developed a robust conversion infrastructure from/to OOXML and IDML and other XML formats, such as the central Hub format that uses CSSa, as presented in Prague. These converters are based on the XML stack, namely on XSLT2 and XProc. Nowadays, even in publishing, XML technologies compete with other approaches (HTML5/Python, HTML5/JSON/JS, …). So in order to maintain and demonstrate the stack’s validity, it should matter to us that we create mindshare, i.e., that both customers and competitors approve of that technology stack and use it, too.

Saxon CE and our tools have in common that the money has already been spent on developing them.

Conventional thinking knows two principal ways of monetizing these tools: either selling (licensing) them or not disclosing them and therefore being able to offer one’s services more cost-efficiently than the competitors.

What conventional wisdom overlooks is that adopters of a technology or a tool don’t merely buy the tool for what it does. They buy into an ecosystem. They don’t want to be left alone with their tool vendor. Even when they buy a tool that a single vendor controls, such as SAP or Microsoft, there’s some assurance that the tool will continue to be supported at more or less the same terms.

To buy a proprietary tool that only three developers in the world maintain, and where these three developers are working for a single small company, is risky. The company may cease to exist, key developers may leave, the product may become out of focus if the user base is too small or if it doesn’t generate substantial revenues, etc.

So a way forward may be to open-source the product and broaden its user base. But how will the product generate the revenues to sustain its development if it is open source?

Another concern, maybe less for Saxonica than for my fellow managing directors, the shareholders of le-tex: If we open the tool that has helped us maintain a competitive edge over our competitors, why should we sacrifice that competitive edge in giving the competitors the tool for free?

I’ll try to address the second concern first. First there’s a natural inertia and a not-invented-here attitude that keeps competitors from adopting our tool. Maybe their toolchains are so different from ours that our tool doesn’t add much value for them. Or they have similar proprietary tools for internal use. There will be many reasons for competitors not to adopt our tool. While this probable non-adoption may refute the argument that competitors will get the better of us, for free, it amounts to admitting that the tool won’t be broadly adopted. The tool being open source may then somehow appease the customer who is unwilling to buy proprietary software that only one single shop controls. But at least among customers in publishing, it isn’t the proprietary nature of tools that stifles adoption, it’s rather their lack of proven acceptance in the marketplace, their niche or even esoteric nature.

So hoping for non-adoption among competitors obviously doesn’t solve the adoption issue. The tool has to become mainstream, and this can only be achieved by pulling customers and competitors into that methodology. To spread the news about the superiority of our proprietary tool is beyond our marketing and sales capacity, and it’s increasingly hard to introduce high-priced infrastructure products in markets where databases, operatings systems, development tools etc. are free. Apart from that, our tool builds on a stack of open-source tools such as Saxon HE and XML Calabash, and the tool or its methodology aren’t exactly rocket science. To the contrary, they epitomize the way that we think that everybody should use the basic tools to convert the standard XML-based input formats to XML-based output formats. They are to us, so to say, the categorial imperative of data conversion, and of course it’s non-sensical to treat such a universally valid guideline as proprietary intellectual property.

What will happen if competitors (= partners), customers and other entities (the not-yet-customers) start using our tools?

Indian partners might use the tools for their English-speaking customers. If they have special requirements, the customers are likely to ask us, the tool’s initiator, to extend the tool with a certain functionality. This has worked for companies such as 37 Signals who are in a position to pick the customers that they provide with Rails-related services. And they can charge a premium for these services because they are the initiator.

The English-speaking publisher market has been virtually inaccessible to us because there’s a plethora of (mostly) Indian vendors who are able to offer commodity services at a lower price, at least for English-language publications. But also in our domestic market, it’s probably true what our partner/competitor Manuel Montero Pineda told me after our open-source announcement: If his company uses our tools and a customer requests a modification, given their developers’ high degree of utilization, they won’t spend weeks or months to investigate the internals of the software and modify it. They’ll rather ask us to do the job, yielding revenues from a customer that we didn’t “own”, and doing so without any sales effort on our part.

I’m confident (although I cannot prove) that these additional effects will outweigh detrimental effects where competitors will be able to snatch away a customer because, thanks to the tools that we developed, they are able to charge less (because they don’t have the development costs) for the same services, using our tools.

But what’s the revenue model then? Only in rare cases can you argue that you had the development costs anyway, for creating internal-use tools, or that you also get some payback from others who extend the tool that you initially have open-sourced.

I see the following sources of revenue:

• Customers paying for new features;
• Customers paying a premium for services around the tool (because you are the 37 Signals in your space);
• Hosted solutions that are built on the tool and that subsidize its development;
• Support and consultancy;
• Voluntary contributions by customers. We have already requested and received these, but it has proven difficult to explain why a pilot customer has to pay for a feature when subsequent customers get it for free. This sense of unfairness is similar to what my colleagues feel about funding development and then let our competitors use the tool. In markets such as Norway, this model of funding open-source development is much more accepted than in Germany, because the customers are well aware of the fact that they also profit to a large degree from developments that someone else has subsidized. It’s all a matter of education, I guess (or is it a matter of abundant petrodollars, coupled with Scandinavian common sense?): Do you want to use BaseX without licensing fees and maybe pay $ 7,000 for a certain feature that you need, or do you want to spend $ XX,000 upfront for MarkLogic that already has this and other features? It’s important to tell people that sponsoring open-source development is in their mid- to long-term financial and strategic interest;
• Maintenance fees, compatibility assurance: We have successfully sold our newly open-sourced toolchain to a German publisher because we promised to open-source it (otherwise they would have selected a solution from another vendor). Apart from man&material fees for further developing the tools and for configuring them, we offered an upgrade/compatibility assurance that is comparable with the 18 or so percent annual maintenance fee that commercial software vendors charge. This assurance covers that we keep a copy of the customer’s customization in our continuous integration infrastructure, and we define and continuously improve test sets taken from the customer’s documents. Whenever we change our basic tools, we will know if something will break if we deploy an update at the customer’s site. And we’ll make sure that nothing breaks or otherwise find a solution what to change in the basic tool or in the customer’s installation so that they can use the most recent versions of our basic tools. Of course this is a service that you can charge for. Of course providing this service costs you something. But you can organize these tests alongside your other CI tests in an efficient manner so that there will be profits to subsidize further development. On the other hand, the customer would have to spend much more if their own people were responsible for integrating our patches to their infrastructure. Simply because we would create these patches without checking for compatibility with their installation, and because they don’t have a sophisticated CI infrastructure. I think that this kind of assurance service may also be provided by Saxonica for Saxon CE: offer the infrastructure for customers and system integrators to upload their applications and run Selenium-like test on them, and run these tests automatically against Saxon CE release candidates.
• Offering training and certification: We develop tools but we are primarily a provider of integration, conversion, typesetting, hosted solution, and support services. Saxonica, on the other hand, primarily develop tools. Apart from charging for implementing certain features or receiving direct subsidies, they cannot subsidize development by other services. But they can train integrators and certify them and their solutions. This won’t cover all development costs and incurs additional costs, but it may provide some compensation;
• Contributions by organizations with a vested interest in the tool. For Saxon CE, this could be an organization such as Mozilla Foundation, although this seems unlikely, given their current focus on Javascript, DOM, CSS and other non-XSLT technologies. It could be NIH for a Saxon-CE-based, Web XML editor that allows editing JATS. It could be a consortium of publishers who need a configurable HTML5 editor with different kinds of XML output. We are currently plotting a deal with some German publishers. Part of that deal would be a contribution to the development of the open-source Saxon CE product (for example, what they’d save in comparison to the hitherto existing per-site licensing fees).

To sum up: I think there is more opportunity in open-sourcing tools such as Saxon CE or our conversion toolchain than it is in keeping them closed. It is important to create mindshare both with respect to the technological merits of these approaches and with respect to funding models beyond conventional licensing.

In TeX, you’d define some macro as \discretionary{\hyphenchar}{}{|}. In InDesign, however, I fumbled with Ligatures and other OpenType features such as falt (Final Glyph on Line Alternates). Alas, InDesign doesn’t seem to support falt yet.

To my rescue came TeX, in the form of Liang’s seminal hyphenation patterns. They found their way to InDesign via OpenOffice, which uses Hunspell, which in turn uses (essentially) Liang patterns for hyphenation.

I created a new language variant under de_DE with an arbitrary name, and placed a file hyph_de_DE.dic in there with the following content:

UTF8
7|/=-

I introduced it to InDesign (CS5.5 or newer) by following this step-by-step guide.

What I didn’t find out is how to name this new language variant. So I created a character style with this nameless language and assigned it to the bar-bearing phrases.

Other hyphenation patterns didn’t seem necessary. This is because the bars in the input represent all legal hyphenation positions. The only requirement was to allow line breaks at the bar positions and turn the bars into hyphens when there’s a line break at their position.

It has proven useful when writing portable Makefiles that work on Cygwin and Unix-like systems when Java is involved. The issue with Java and Cygwin is the following. Suppose that you have installed Cygwin in C:/cygwin and you have installed Java SE for Windows. Then if you want to refer to a file /home/gerrit/test.xml you’ll have to translate the path to C:/cygwin/home/gerrit/test.xml. There’s a cygwin utility, cygpath, that works similar to realpath(1) in that it can translate a filename to its (Windows) full name, including the directory. For example, when I invoke cygpath -ma test.xml in my home dir it will give me C:/cygwin/home/gerrit/test.xml, the full path, as suitable for Java.

Trying to use relative paths throughout proved to difficult, since different tools assume different base directories for files. An XSLT 2 processor, for example, will try to resolve  a pathless file name relative to the stylesheet’s directory, so you’d have to figure out what the relative path to your file from there will be. Another XSLT processor requirement (depending on you configuration) is that it wants to have URIs for files. In above example, it will expect file:///c:/cygwin/home/gerrit/test.xml as a file name argument, while you can just pass it /home/gerrit/test.xml on Linux.

The most elegant solutions (at least if you stick with make and don’t use XProc for automation, which has its own peculiarities) is to use a make function like this:

ifeq ($(shell uname -o),Cygwin)
win_path = $(shell cygpath -ma $(1))
uri = file:///$(call win_path,$(1))
else
uri = $(1)
endif 

Here’s an application example that uses the uri function twice:

%.idml.HUB %.idml.INDEXTERMS %.idml.TAGGED: %.idml Makefile xslt/*.xsl xslt/modes/*.xsl
mkdir -p $<.tmp
unzip -u -o -d $ $(SAXON) \
$(SAXONOPTS) \
-xsl:xslt/idml2xml.xsl \
-it:$(call lc,$(subst .,,$(suffix $@))) \
src-dir-uri=$(call uri,$ $@

It also features a function lc that converts its argument to lower case. It is defined as

lc = $(shell echo $(1) | tr '[:upper:]' '[:lower:]')

Makefile functions don’t survive export

When a sub-make is called, the function is exported as a plain variable rather than as a function, and the variable is expanded on the way. This issue is already described in a post on stackoverflow. Moving the function definition to another file that is imported by both Makefiles will improve the situation.

But today I ran into an issue where a Makefile invoked itself recursively and exported all of its variables. My user-defined function, even when reduced to a simple cat $(1), didn’t finish. This was also true when I outsourced the function definition to an included file, because the exported variables supersede the default definitions. So because $(1) was expanded to the empty string, the function that the sub-make called consisted of a mere cat, without argument placeholder, that was waiting for someone to feed it via STDIN.

The solution consisted of unexporting the function/variable:

# export all variables:
export
# except for the testfunc function:
unexport linecount
linecount = $(shell wc -l $(1))

test1:
$(MAKE) test2

test2:
@echo $(call linecount,Makefile)

Invoking this yields:

$ make
make test2
make[1]: Entering directory `/home/gerrit'
11 Makefile
make[1]: Leaving directory `/home/gerrit'

Commenting out the ‘unexport’ line gives the following output

$ make
make test2

and it doesn’t finish, because wc is waiting for input on STDIN.

To be continued…

I recently discovered (and needed, and used) secondary expansion, a true makeshift that I will deal with in another post. There you’ll get a glimpse why this kind of tinkering with good old make and its expansion mechanism was probably the last straw that have made others concoct cleaner alternatives to make, such as ant or XProc. But never forget that these features, such as call, eval, and seconary expansion, give you “all the configurability and flexibility of Sendmail”. Take dynamic evaluation. You have it in XProc processor vendor extensions, but not in ant (maybe with Jelly, I don’t know this stuff too well). Make is still our favorite process automation tool. Maybe XProc V.next, that will hopefully deal better with non-XML files, will be a runner-up.

It is built on Saxon CE, Saxonica’s XSLT 2.0 processor for browsers.

The code is on github. However, you need to obtain a Saxon CE license in order to deploy your own derivative solutions.

What can be done about it? A couple of things.

• Establish a low-cost production line and rigidly define what is included in the price and what is not. The drawback is that the surcharges that you inevitably charge will contribute to the average cost per page, making you still more expensive. But at least the reasons become much more transparent.
• Raise awareness that there are different production categories. The customer might already have different production categories. Convince him that the criterion whether a book is typeset in a standard layout or whether the author used a template is not sufficient.
• Emphasize the role of the intake report. Establish automated tools for checking adherence to templates, image profiles, etc.
• Establish a Web-based frill counter where you document the production editor’s or author’s special requests. For titles that are supposed in a standard workflow,  ask a customer’s representative to approve every single deviating requirement.

These measures will assist the customers in improving their own processes and hopefully in moving away from underparameterized per-page pricing expectations. Per-page isn’t going to work in the long run, since more and more publications will be unpaginated. However, moving from page to kilobyte metrics won’t be a solution.

To answer the initial question: a boutique shouldn’t necessarily sell commodities. However, flat, per-page price comparisons might suggest diluting boutique production prices with commodity prices.

Another reason for us as a boutique to keep standardized, high-volume production is: not only do we deliver boutique production, but also boutique workflow consultancy and automation. In order to fully understand high-volume production requirements, we have got to do it ourselves. Therefore, we as a boutique do also strive to sell commodities, against all odds.

• not including the namespace prefix
• typo in the namespace URI
• processing the document in a different mode than the template is supposed to match in
• other typos (in predicates, element names, modes)
• skipping intermediate elements, e.g., formulating predicates for <td>s when the template is supposed to match <tr>
• other templates have higher priority
• import precedence: this template is an imported one, and there is a matching template of whatever priority in the importing stylesheet, or in a template imported after the template in question
• logical misconceptions in the predicates
• if the template is supposed to match a result of a previous transformation: the output of the previous tranformation is not as expected
• processing some surrounding element with xsl:copy-of instead of xsl:apply-templates

My tactics of debugging these cases include

• to make the non-matching template increasingly less specific (dropping terms in the predicate),
• increase the priority to insane values,
• make the template output debugging info such as “I’m here”, or count(*) and count(B) in the context of A (first make sure that the template matches A – ‘I’m A’),
• output intermediate processing steps to a file (<xsl:result-document href=”_debug.35.fooify-bar.xml”><xsl:copy-of select=”$foo”/></xsl:result-document>)

Schema-aware processing will probably help detect many of the issues, too. But I have to admit that I don’t usually undergo the effort of creating schemas for intermediate transformation results.

Templates that match too much

This might also happen, and in fact a template that matched unexpectedly many nodes was the reason that I wrote this post.

Last night I spent hours debugging this template:

<xsl:template match="ParagraphStyleRange
                       [count(XMLElement) eq 1]
                       [every $x in descendant::XMLElement
                         [ancestor::ParagraphStyleRange[1] is current()/..]
                         satisfies (
                           not($x/XMLAttribute[@Name = 'aid:pstyle'])
                         )
                       ]
                       [every $c in CharacterStyleRange satisfies (matches($c, '^$'))]
                     /XMLElement
                       [not(every $c in * satisfies ($c/self::Table or $c/self::XMLAttribute))]"
              mode="idml2xml:GenerateTagging">
  <xsl:copy>
    <xsl:copy-of select="@*" />
    <xsl:apply-templates mode="#current" />
    <XMLAttribute Name="xmlns:idml2xml" Value="http://www.le-tex.de/namespace/idml2xml" />
    <XMLAttribute Name="idml2xml:AppliedParagraphStyle" Value="{replace(../@AppliedParagraphStyle, '^ParagraphStyle/', '')}" />
    <XMLAttribute Name="idml2xml:reason" Value="gp3" />
  </xsl:copy>
</xsl:template>

This is an example from an IDML processing pipeline as described in the ropes of sand post. After splitting the text at every paragraph break, I want to attach pstyle information to elements that span a whole paragraph and that don’t already carry an aid:pstyle attribute. But there may already be XMLElements carrying a pstyle that are not immediately below the ParagraphStyleRange element. So in lines 3–8, I’m filtering the template to apply only to non-pstyled XMLElements. Caveat: there may be embedded ParagraphStyleRanges further down, for example, when there’s a Table or another Story contained in this range. So I’ll have to exclude XMLElements that are located in embedded ParagraphStyleRanges. And that’s what I originally wanted to check by applying the condition that every XMLElement[ancestor::ParagraphStyleRange[1] is current()] doesn’t have a pstyle. current() was working well as long as the template matched ParagraphStyleRanges. But then I modified it to have the current form, to match ParagraphStyleRange/XMLElement. Then suddenly it matched many more XMLElements, including such that had a pstyle attached to them. Why?

The reason is that by modifying the pattern from A[…] to A[…]/B (where A stands for ParagraphStyleRange, etc.), the term current() in A’s predicate no longer referred to A, but to B!. Therefore the condition [every $x in descendant::B[ancestor::A[1] is current()] satisfies …] was always true because in no circumstances may there be an ancestor::A that is of type B. And if the sequence after “every $x in” is empty, the “every … satisfies” clause is always true. Therefore my filter filtered too little of the ParagraphStyleRanges away, so that my template matched too many XMLElements. Changing current() to current()/.. in line 4 improved the situation.

Subtle, subtle. If I had to categorize it, I’d put it into the “logical misconceptions in the predicate” basket.

BREAKING: In #iOS 6/#MacOS 11, Web access only thru proxy.apple.com. Analyst: Web pages bypassing IAP a threat to revenue model

With all the recent fuss about Apple’s In-App Purchase (IAP) API enforcement, the train toward Web apps will take up more traction.

Apple themselves are constantly improving Mobile Safari: it supports most of the events that iOS native apps do support, it is fast enough, and you can imitate a native app’a user experience quite well already. Plus: the Web has gotten really interoperable. You can get almost the same user experience with any iOS browser as with any Android browser without the need to develop for different hardware/software platforms.

German weekly Die Zeit already draw the consequences and abandoned the idea of native apps for their main content.

So in the view of the hefty app tax of 30%, will players such as Sony or Amazon offer their libraries as a pure Web site?

Currently it seems as if they may get Apple’s approval for the apps while still being able to sell content separately. Apple interprets its terms such that vendors may offer an alternative purchase path. This path must not be initiatable from within App store, and the vendors must also offer an In-App-Purchase path (probably at the same end user conditions? Apple will surely clarify this matter soon…).

For impulse buyers, the App store point of sales may be more attractive than going to Amazon’s Web site first, purchasing content and then reading it in the Kindle app. But subscribers of electronic magazines or newspapers will already have a well-established relationship with the publisher’s Web site. So they are likely to extend their existing subscription to the iPad version, not via App store but via publisher’s site, download the free app and start reading on the iPad. The publisher won’t have to pay the 30% Apple tax.

“In their usual cold My Way Or The Highway manner”, Apple will certainly try to close this hole as soon as significant revenues bypass IAP. If antitrust authorities won’t help Amazon and Sony (for which they’ll have to blame Google because the success of Android kept Apple from monopolizing the smartphone/tablet markets), they’ll most probably step out off the App store and move to pure Web offerings. Optimized for mobile, of course, including caching of content, and with a crisp, app-like look & feel.

What will Apple do then? They certainly won’t discontinue Mobile Safari, the tool that enables these Web apps. For some minutes, they might consider disabling HTML forms so that users won’t be able to log in or submit their credit card data to non-Apple services. But this will really break the Web experience; people wouldn’t accept this, and service providers would find ways to GET around these restrictions.

So the ultimate solution will be à la Chinoise: the great filter, or proxy.apple.com (iWall sounds to obstructive).

In order to improve the quality of service, to filter offensive or explicit content, etc. blah, all traffic will be routed through a content delivery network operated by Apple. Apple reserves the right to disallow connections to servers that host content that is discriminatory, sexually offensive, glorifying violence, …, …, …, and it will block servers that offer transactions bypassing Apple’s then-called iPay system. Since this proxy will be built into the devices’ firmware, only jailbroken devices may circumvent this.

The part of the Internet that will be accessible to Apple users will then be known as the iNet. And I’m sure Apple won’t content themselves with fencing in the mobile crowd. Mac users! Not only will you be allowed to taste the sweet and amazingly low-priced App store fruit, you will also be restricted invited to iNet, which means you will also be forced to use iPay for online purchases. Paypal, Visa, Flattr, invoice? These services violate the terms of use and will be blocked.

I wonder why so many morons surrender to Apple so wholeheartedly, for such a small usability or coolness advantage, if any. But I similarly wondered 15 years ago, when I was advocating Linux against Windows. Now my phone runs Linux, and it’s quite usable.

the definition of open: “mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make” (@arubin)

See also:
Mike Cane: The Day Apple Became Nathan Myhrvold (added 2011-02-01 23:25Z)