Mark L. Murphy's Blog, page 7

Random Musings on the Android 15 Developer Preview 1

Wow, it���s February again already?

When Google releases a new developer preview, I rummage throughthe API differences reportthe high-level overviews,and even the release blog post,to see if there are things that warrant more attention from developers. I try to emphasize mainstream features that any developermight reasonably use, along with things that may notget quite as much attention, because they are buried in the JavaDocs.

Last year, a common complaint was how small Android 14 felt. This year, Android 14seems huge by comparison. Android 15 DP1 is so small, Google did not bother writinga high-level overview of the changes, or at least it has not been published in an obviouslocation. Google usually does a bit of ���sandbagging��� in early developer previews,preferring to talk about changes one release later than when they are introduced.Still, this total lack of docs is rather stunning.

What Gives Me Security Concerns

AccessibilityService has long been used for things other than accessibility. Googletried for a while to enforce this at the Play Store level, but if I recall correctly they backed off.

AccessibilityService now offers the ability to attach overlays to displays(and to windows). These are designed for UI that controls the accessibility itself, apparently.

I worry a bit that users will enable accessibility for an app for other reasons (e.g.,help with playing some game), then get bitten by tapjacking attacks initiated by theseoverlays. Hopefully, these overlays have system-supplied ���chrome��� that helps preventthis.

See also getOverlaySupport() on Display.

What Claims to Have Integrity

FileIntegrityManager has beenaround for a few years, but without a lot of functionality. Now we can callsetupFsVerity() for a File,enabling some amount of tampering detection.However, the documentation for applying it (in setupFsVerity()) is seriously confusing.

What We Also Got In Android 14, Sorta

Android 14���s QPR2 added support for partial screen sharing,powered by MediaProjection. This change is also folded into Android 15 DP1.

What Else Is Interesting

PackageManager offers parseAndroidManifest().This is designed for APKs that perhaps have not yet been installed. You get an XmlResourceParserback, letting you traverse the manifest akin to using XmlPullParser.

SystemClock now offers uptimeNanos(), the time since last boot, measured in nanoseconds.

JobManager, via JobInfo, now offers debug tagsand trace tagsfor help with logging and traces.

MediaRoute2Info now supports a bunch of additional remote media routes: to cars, computers,game consoles, other phones, watches, tablets, or docked tablets.

We can now create notifications that have TV extensions,presumably for cases where a phone is tied to an Android TV device.

The parade of screen densities continues, as there is now support for a 390-dpi density.

Security and Third-Party Transports

A couple of weeks ago, news broke thatgovernments might be spying on push messagesdelivered through Apple���s push notification system or Google���s Firebase Cloud Messaging.

(hat tip to Prof. Matthew Green for raising awareness)

IMHO, governments are only part of the problem. Apple and Google can read your push messages.While both firms claim that messages are encrypted, that is only for ���data in motion���, as theyare sent over the Internet. Messages in their servers are unencrypted. Not only can they accessthe data, but they can hand it to whoever they want to, not just governments.

While the current focus is on ���Big Tech��� push message systems, the problem is more generalthan that. Any third-party data transport system has the same sort of problem. Serviceslike PubNub, Amazon SNS, Stream, and others that offer ���publish/subscribe���and similar sorts of message-based APIs are very useful, but generally their data is encryptedin motion and not at rest. Those firms can see your messages, as can anyone that thosefirms allow.

Roughly speaking, I see two main ways of addressing this.

The best is to not send anything of significance in the message itself. Use it asa trigger mechanism only. So, the message might contain some sort of verb identifyingwhat it wants the app to do, but nothing else. The app would then use other communicationsoptions (e.g., Web service calls) to do whatever it is the trigger is requesting. Thisallows you to focus on securing those other communications options, and you care lessabout spying on your messages.

The other is to encrypt your message payloads so that only the recipient can read them.This can work, but key management is a pain as always. IMHO, use this approach only ifthe messages do not require any other communications to be useful ��� if you are goingto have to make a Web service call anyway, there is little value in packing data intothe message itself.

Neither of these approaches help much with metadata. The message system providers (e.g., Google)and their favored partners (e.g., governments) can still examine which apps are getting messages,at what times and for what accounts (e.g., Google accounts). Theonly way to avoid that is to avoid using a message system provider, such as hosting yourown messaging server. That has its own problems (e.g., background process limits in Android).

Using a push message system provider often is unavoidable. Letting them have your data is avoidable,by encrypting that data or not having any meaningful data in the messages themselves.

TV: Now What?

News broke recently thatAmazon might move Fire TV away from Androidand to their own in-house fork of Linux. TV app development would be done in React Native.

This really leaves TV Compose in the lurch. It will be used primarily for Android TV(a small fraction of the streaming device space) and for an ever-shrinking number ofolder Fire TV devices.

However, it further opens up an opportunity for some entrepreneur who wants to go after it.

App development for first-class TV devices will be highly fragmented now:

Roku uses a proprietary language and UI toolkit Future Fire TV devices will use React Native Legacy Fire TV devices and Android TV use Android frameworks like TV Compose Apple TV uses macOS-style frameworks Samsung, LG, and some other TV manufacturers offer their own stores and platforms

Here, ���first-class TV devices��� means devices where the app is installed on the device.Platforms like Chromecast, where the app is installed elsewhere, work substantially differently.

To me, this level of fragmentation, coupled with the nature of content-centric TV apps, suggests thata server-defined UI approach might work well. The TV apps would be largely white-labeledcontainers pointing to dedicated endpoints that serve the UI and the content viewed bythat UI. Part of that server-defined UI would be a ���stylesheet��� for branding elements(color scheme, logos, etc.). The browsing and playback UI would be driven by a mix ofthe available content and some general presentation patterns, with customization as desiredby the customer.

I am uncertain if Roku���s system will support this approach, as it is very proprietaryand reminds me of 1990���s Visual Basic as much as anything.

It used to be that Roku plus Android would be 80+% of the North American TV streamingmarket. Eventually, that will become Roku plus React Native, as Amazon migrates to thenew OS. Perhaps some enterprising developers will come up with something interestingto help bridge this gap and pick up the other smaller platforms as well.

Testing the Limits of Anti-Competition

The latest Play Console restrictionis a testing gate:

developers with newly created personal Play Console accounts will soon be required to test their apps with at least 20 people for a minimum of two weeks before applying for access to production

This seems trivial to bypass ��� 20 sockpuppet accounts anda test monkeymight suffice. One imagines that somebody will create an underground service for this.

But Google can enact policies like this without much concern, as thereis nowhere else for developers to go, by and large.

That���s why it will be interesting to see if Epic v. Googlewill touch upon a key anti-competitive tactic: banning app distributors from the Play Store.If your app���s principal job is to help people install apps, you are out of luck. Eitheryou need to be a device manufacturer (e.g., Samsung) who can pre-install a store, oryour potential users will need to sideload your store.

If this ban could be removed ��� by lawsuit or by legislation ��� there could be amore concerted effort to offer the Play Store meaningful competition. Even if Google were to continuewith its policies, the competition would mean that there would be other useful avenues foraffected developers to use.

The Omega and the Alpha

This is the seventh and final post in a series where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

The series:

Waiting for a Chasm-Crosser Settling on a Business Model Dynamic Books Android or iPhone? The Summer of Silence Movin��� On Up The Omega and the Alpha

As noted in the previous post,I had a lot of success in the early years. Things might have peaked for me in 2014-15, whenI had the opportunity to train hundreds of developers at a device manufacturer that wasmoving into Android��� and then subsequently moved out of Android. ����

Perhaps that was foreshadowing, because by 2018, it was fairly obvious to me that CommonsWarewas ���circling the drain���, and there wasn���t a thing I could do about it.

So, what happened?

As I noted earlier, I am not a marketer. CommonsWare���s marketing pretty much boiled downto: be useful to a large audience and hope that you get enough���true fans��� tokeep the business afloat. This is not a bad approach when you can be ���a big fish in a small pond���.It does not work as well once the pond grows a lot, and in the case of Android, the pond grewto be the size of the Pacific Ocean. Either you:

Find some shallow eddy in which you can still be a ���big fish���, by focusing on some nichewhile sticking with the same word-of-mouth marketing

Adopt other forms of marketing, or relationships with larger brands, that allow you todeal better with a larger set of competitors

Drown

I drowned. I did not plan ahead for finding some smaller niche, and I did not have any cluehow to do anything else to keep CommonsWare at the forefront of developers��� minds.

By 2018, I started doing contract development work. I knew that the time I was working on contractswas time that I was not investing in CommonsWare���s future. I did, though, elect todeclare ���tech debt��� on The Busy Coder���s Guide to Android Development and started inon the second-generation books, such asElements of Android JetpackandExploring Android.But I knew, even as I was writing those, that I didn���t have much of a prayer with the Warescriptionmodel. I had too few subscribers and no clear plan for how to get more.

So, I did what a lot of people would do in that situation: I succumbed to depression.Or, in the words of Britain���s greatest secret agent:I lost my mojo.

In August 2019, through the efforts of Touchlab, I wound updoing contract work with a company called MIRROR. They made a fitness mirror, one whereyou can see the instructor and yourself while doing yoga, strength training, pilates, cardio work,stretching, etc. At the outset, that was just another contract.

In early 2020, I cut that contract to part-time status. I had one last shotat salvaging CommonsWare: dive into the niche of Jetpack Compose. I starteda Jetpack Compose newsletter and had plans for books and a lot of the thingsyou see others doing, such as an online catalog of composables and how to use them. My planwas to keep MIRROR going on a part-time basis as long as practical, while using the time to buildup Compose expertise and content, in hopes of re-establishing myself.

But in June, MIRROR asked me to come back as a full-time contractor. I knew that if I did that,I had no shot at saving CommonsWare. But, I was tired and depressed, and I felt like CommonsWare hadrun its course. Plus, I really liked MIRROR, even after it was acquired by lululemon. So,I returned to full-time contractor status. And, in late 2021, I joined up as a regular employee,published the final edition of my books, and shut down CommonsWare.

2022 was a rough year for me emotionally. While I enjoyed the work with MIRROR, I was stilldepressed over my ���failure��� with CommonsWare��� ignoring the fact that having the businesssurvive that long and do as well as I did was a massive achievement. Few startups survive fiveyears, and fewer still make it past their first decade. I beat both of those. Few developerswill ever get the name recognition that I once had, and to a lesser extent perhaps still do.Yet, I could only focus on the fact that I couldn���t sustain the business over the long haul.Plus, being in my early 50s, I felt like being an entrepreneur was something I might never do again.

Which brings us to 2023.

Early this year, I was inspired, not once, but twice, to turn my life around.I came to grips with my emotional state and got into therapy. I lost 25 pounds (hey,those MIRROR workouts really do work!). I saw what I was missingprofessionally due to my depression, and I finally got past the end of CommonsWare.I once again saw the joy in what I could do, and I started feeling like the MarkMurphy of old, for the first time in years. I started doing some ���extracurricular��� things totry to help MIRROR (n��e lululemon Studio), and while those may not ever have an impact, Ifelt good for trying to ���move the needle��� and make a substantial impact.

And now? I have plans for some more books. I am making no promises, but watch this spacefor further developments.

I learned a lot during the CommonsWare years, about myself perhaps more than aboutAndroid. For example, at times I was not very nice, and I will be forever chagrinedat aspects of my behavior. While it is a clich�� to say that ���I have become a better person���,in my case I think it is true.

I am forever grateful to the Android developer community, from the experts to the newcomers,for helping to grow Android to what it is today and to give me the opportunity to be useful.I am thankful for my colleagues at MIRROR lululemon Studiolululemon, for putting up with my foibles and letting me help along the way. And I willbe forever in debt to the person who inspired me twice this year to turn things around.

If I may be so bold to provide some advice, based on all of this:

Don���t be afraid to chase your entrepreneurial dreams. The likelihood of cataclysmicfailure is very low. The most likely form of ���failure��� is just to fizzle, and while itwill seem painful in the moment, you will be fine. The possibilities of success, andthe joy you will get from that success, are far more than worth the fizzle.

That said, if you start a business, do not only have a plan at the outset. Have a meta-planfor how you will adapt your plan to changes in the marketplace, in your situation, etc.Be in position to ���take a step back��� and look at your efforts with a clear and unbiasedeye. And don���t be afraid to change that plan��� so long as you are not doing so on a whimand without clarity for how those changes will help.

Introverts can be entrepreneurs. Ask me how I know.

Be kind, and find ways to be kinder tomorrow than you are today.

Movin��� On Up

This is the sixth of several posts where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

The series:

Waiting for a Chasm-Crosser Settling on a Business Model Dynamic Books Android or iPhone? The Summer of Silence Movin��� On Up

In 2009, things started to pick up. As carriers started offering Android devices ���and while Apple was only slowly reacting ��� interest in CommonsWare climbed:

I started delivering professional training on Android app development. Some ofthat was private for specific firms looking to jump on board Android. Some ofthat was public training, as I was the inaugural Android trainer forBig Nerd Ranch. The Big Nerd Ranch relationshiponly lasted a couple of years, as I was a contractor, and they eventuallyset up their own trainer talent. However,I struck deals to deliver training on behalf of other training firms in the USand Europe.

I entered an arrangement with Apress to re-publish The Busy Coder���s Guide to Android Developmentas Beginning Android. We did a few editions of that book together ���I would distribute my copies, and they would distribute theirs. Eventually, I declinedto continue with them, as sales of the Warescription (my subscription offering) outsoldthem by a lot, just on unit sales. Plus, direct sales of digital books had a lothigher profit margins than the royalty rate I got from Apress.

I started writing the occasional column for places like InfoWorld, before eventuallysetting up this blog and focusing on it.

All of that allowed me to quit my day job and work on CommonsWare full time.

I added ���office hours��� chats as a subscriber benefit, where I would hang out in a chatroom for an hour and field whatever questions came up. That ran for a decadeand probably contributed some to sales.

I also saw this little developer support site called Stack Overflowstart to get some traction, and I decided that maybe I could help there.I answered my first question in May of 2009��� and just kept going.Right now, it is up to 22,879 answers,though my contributions have definitely tailed off in the past several years.

Soon after, conferences started paying attention to Android. My first conferencepresentation was in 2010 at the Rich Web Experience, and the AnDevCon series beganin 2011. All told, I presented at 38 conferences between 2010 and 2019. At severalI delivered multiple presentations, so my total presentation count is probably around50.

And the books flew off the (digital) shelves. I originally published both print editions(sold via Amazon) and the Warescription. In 2012 I discontinued the print editionsbecause they did not sell very well and I was writing too much. Even at $40, then $45, peryear, I had ~2,500 subscribers through 2015.

Not everything worked. I dabbled in developing libraries (the CommonsWare Android Components, orCWAC). For the early years, they were OK, but by modern standards they were awful.I tried various ways to extend the value of the Warescription, such as includingtraining videos with the (self-distributed) book app. That didn���t get a lot of attention,and I eventually stopped distributing the book as its own APK.

Still, though, I was doing quite well, professionally and financially, despite havinglimited marketing presence outside of ���doing good stuff���. However,what goes up must come down, and I will explore that in my next and final postin this series.

The Summer of Silence

This is the fifth of several posts where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

The series:

Waiting for a Chasm-Crosser Settling on a Business Model Dynamic Books Android or iPhone? The Summer of Silence

To recap: in early 2008, I realized that Android was the best option for me to divedeeply into smartphones, rather than iPhone. And I thought that a business model based aroundfrequently-updated books on rapidly-moving technology might work.

So, I started writing. I spent evenings and weekends coming to grips with thenascent Android SDK, writing book chapters and sample apps along the way.

I also started contributing on the two Google Groups that Google had set up forAndroid app development support. I knew that ���word of mouth��� was going to be key formy success, so I wanted to start early. However, in April and May of 2008,I was definitely helping more on thefringes ��� most of the attention in those groups were on the Google engineersworking on Android. Legends like Dianne Hackborn were active in the groups, guidingus in understanding thorny questions like ���WTF is a Context?��� and ���why does my activityget screwy after I rotate from portrait to landscape?���. There were perhaps a dozenkey Google contributors on those groups, and we relied on them fairly heavily.

And then in late May, the Google contingent stopped posting on those groups.

There was no ���goodbye���, or ���hey, we need to focus on other things for a while���,or any other sort of announcement. One day, they were just gone. Eventually, weheard via ���the grapevine��� that top management (presumably Andy Rubin) had screamed fairly loudly aboutGooglers being involved with the community, particularly with deadlines looming. That seems plausible (both the justification and the screaming), though I neverattempted to get corroboration for that story.

The reverberations from that lingered for years, as it seemed as though Google engineerswere prevented from even acknowledging that the community existed. I distinctlyremember an early Google I|O conference session, where Romain Guy was struggling not tosay ���ActionBarSherlock��� when tryingto answer a question about ActionBarSherlock, Jake Wharton���s legendary early UI framework.It was quite some time before whatever sortof ���gag order��� they were under seemed to lapse, and longer still before Android got a soliddeveloper relations team.

But, in May 2008, the net was that the vast majority of our Android developer support systemvanished without a trace. It was just a few of us independents left to help others, especially those like myself and Reto Meier,who were working on Android app development books. I re-doubled my support efforts, to tryto fill the gap. And, weeks after the summer of silence began, I released the initial edition ofThey Busy Coder���s Guide to Android Development.

The combination of the book and the support posts on the Google Groups started to establish my reputation as being a leading expert on Android app development.

This is where ���you make your own luck��� starts to come in. I did the work to identifya business model. I did the work to identify an area to apply the business model towards.I did all kinds of work to execute on that business model, starting with writing a book very quicklyand supporting the pre-hardware Android developer crowd. That set me up to capitalizeon the ���knowledge gap��� that arose when the Google engineers left the Google Groups.I did not create that gap ��� some Google executive did ��� but I was in positionto fill it. The phrase really should be ���you work to put yourself in a place to leverage luckwhen it arises���, but that���s a bit wordy.

Those Google Groups have long been ���resigned to the dustbin of history���, and evenold-timers like myself rarely think about them. I wound up being better known foranswering support questions somewhere else��� and I will talk more about that ���somewhere else���in the next post in this series.

Android or iPhone?

This is the fourth of several posts where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

The series:

Waiting for a Chasm-Crosser Settling on a Business Model Dynamic Books Android or iPhone?

Rolling back to where the first postended, in late 2007:

Apple announced that they would have a real SDK for developing iPhone apps in early 2008

Google released the first developer preview of Android

I started experimenting with Android. The SDK was a bit odd, and the docs were a bit modest,but for a developer preview, it was reasonable. Moreover:

It was based on Java, and I had a reasonable amount of experience with it

It was open source, and I was a definite fan of that, to the point where my ���daily driver���machine was powered by Linux

At the time, I trusted Google far more than I trusted Apple

However, Android was still just a preview. As it turned out, it was nearly a year untilhardware became available to the public. Apple was already shipping iPhones. If you comparesales back then to today, Apple was not selling very many iPhones. It was quite some timebefore Android devices surpassed iPhones in sales. And, as 2007 came to a close, it wasfairly clear that the iPhone SDK would do better ���out of the gate���, just because they hadan active user base.

So, I waited.

On March 6, 2008, Apple released their SDK. From my vantage point, it was an unmitigated disaster:

It was based on Objective-C. I remember when Objective-C came out ��� I looked at the syntaxand wondered why anyone would use it.

It was based on Cocoa, the macOS/OS X UI framework. I had noexperience with that. Of course, I had no experience with Android���s widget set either, butat least there, I was on a level playing field with just about everyone else. I expected thatmacOS developers would be in better shape to develop iPhone apps than I would be.

It required a Mac for development. This wasn���t the end of the world, as I used to use a 15���iMac as my main desktop and so had OS X experience. Still, it wasn���t what I wanted.

Most importantly, you had to sign an NDA. It is very difficult to write books when you are notallowed to write books. It is very difficult to answer developer questions when you are notallowed to answer developer questions. And so on.

Shortly thereafter, I turned my attention to Android, and a few months later, I had an early editionof The Busy Coder���s Guide to Android Development available. And, in October 2008,I waited in the early hours of the morning outside a T-Mobile store in the greater Philadelphiaarea, to beat the rush of people who I was sure were going to line up to purchase the T-Mobile G1(a.k.a., the HTC Dream), the first widely-available Android phone in the US.

As it turned out��� I was the only one waiting. And the guy at the store thought I was nuts.

In a parallel universe, Android ���died on the vine���. In this universe, Apple���s hubris bitthem in the posterior once again. In the US, they established AT&T as the exclusive carrierfor iPhones. The other US carriers struck deals with HTC, Motorola, and others for Android phones,giving Android an opening. By the time Apple relented and got iPhone models available for allthe major US carriers, Android was established and would go on to global dominance.

Android���s success meant that I had the potential for success, ���riding the coattails��� as it were.It still was far from guaranteed that I would do well. Fortunately, 2008 gave me an opportunityto establish some credentials, a topic that I will cover in the next post.

Dynamic Books

This is the third of several posts where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

The series:

Waiting for a Chasm-Crosser Settling on a Business Model Dynamic Books

Part of the challenge in explaining where CommonsWare came from is that so much has changedsince the mid-2000���s. What was innovative at the time is fairly ordinary today.

Nowadays, online documentation for operating systems, programming languages, libraries, and toolsis not merely expected to exist, but to be good. 15 years ago, that would have beenunrealistic. We were lucky to have any of that. Instead, most ���bulk form��� knowledge transfercame in the form of books from traditional publishers: O���Reilly, Apress, Prentice-Hall PTR, andvarious others.

Traditional publishers, particularly at that time, were far from nimble. It might take 6-18 monthsfor a book to get published. That was a big problem for fast-moving technologies ���by the time the book ���hit the shelves���, it was already at risk of being out of date. And whilee-books existed, if they were published by traditional publishers, they had the same publishingworkflow and the same publishing delays. Besides, e-books were fairly new ��� the Amazon Kindledid not debut until November 2007, around the time that Android was announced.

At that time, I was fairly certain that e-books would do well for programming guides and similarsorts of book subjects. However, since e-books were still nascent, banking a business on themseemed risky. At the same time, my vision for CommonsWare was to provide up-to-datehelp for programmers, and traditional publishers were far too slow.

Fortunately, I stumbled upon Lightning Source.

Lightning Source offered print-on-demand services,and through Ingram were tied into Amazon. You could self-publish a print book on Amazon withouthaving to have pre-ordered hundreds of copies of the book. Instead, Lightning Source wouldrespond to an Amazon order by printing a single copy of the book (or however many were ordered)and shipping it to the customer directly. This meant I could control my own publishing timelines,simply by listing an updated title on Amazon with fulfillment handled by Lightning Source.Much to my amazement, the quality of the book was very good, more than sufficient for my needs.

Lightning Source for printed books, coupled with e-books, meant that I could offer continuously-updatedcontent:

I could sell e-books on a subscription basis, publishing updates as frequently as I wanted,to track changes in a subject or to expand coverage

I could sell print editions of that same content via Amazon, updated less frequently than thee-books (say, once per year), but still much more frequently and quickly than any traditionalpublisher could match

Nowadays, this is all taken somewhat for granted. Selling subscriptions to continuously-updateddigital content, even by solo entrepreneurs or on a hobby basis, is commonplace.At the time, very few people were doing this, and I was breaking new ground to an extent.

In terms of the business model,I did not want to charge a lot for the e-book subscriptions ��� I wanted it to be in linewith books, though perhaps on the more expensive end. I settled on $45 per year. Profit margins on self-published and self-sold e-books were tremendous, as I only had to pay credit card processingfees (or the equivalent for services like PayPal). ~95% profit margin is quite a contrast from self-publishedprint books sold through Amazon (~55% profit margin), let alone royalties from traditional printpublishers (equivalent of ~10% profit margin). Still, I would need more than ���1000 true fans���, but Ihoped that I would ���make it up in volume���. Plus, I thought that maybe I could offer some professionalservices to supplement the book publishing, such as consulting or training.

So, I had the the ���reason to buy���: get up-to-date programming guides in what was for the time afairly convenient format (e-books). I still needed to settle on the specific subject matter: Androidor iPhone. That not only meant what area I would need to focus in, but also what avenues I woulduse to ���connect with fans���. I will explore that decision in the next post.

Settling on a Business Model

This is the second of several posts where I am revisiting CommonsWare, my long-timebusiness and current ���hobby with a logo���. I thought it might be useful to some tosee how all that came about, the decisions I made, and so on.

The series:

Waiting for a Chasm-Crosser Settling on a Business Model

One of the things I learned in my early entrepreneurial ventures is that I have zeromarketing sense. That���s a slight problem for many businesses. I ���kept my ear to the ground���,trying to identify some approach to business that might work despite my shortcomings.

In March 2008 ��� as I was deciding whether to try to do something with iPhone or Android ���Kevin Kelly published his 1000 True Fans post.He rightfully points out that many markets have a long-tail distribution,where the majority of success goes to a handful of participants. However, he posited thatthose in the long tail could still enjoy success, by focusing on wide reach and upsells tointerested parties (the 1,000 ���true fans���). He wrote in terms of the music industry, arguingthat musicians ought to worry less about music piracy (a big concern in 2008). Instead, they shouldembrace free music distribution, simply to try to have wide enough reach to get enough ���true fans���who would be willing to purchase stuff in furtherance of their fandom.

In May 2010 ��� after CommonsWare was already underway ��� Mike Masnickexpanded on this approach with his ���connect with fans / reason to buy��� model.(or ���CwF+RtB��� for short). Still, it���s the same basic idea: cast as wide a net as possible, and have opportunities forenthusiasts to expand their experience for a fee.

Nowadays, this approach is well-known. Many people blog, do podcasts, or answer questions as away of becoming well-known in a space, then use that reach to convince some subset of their audienceto pay for books, training, consulting, etc. The ���influencer��� model is the epitome of this:their reach is so broad that they are pure promotion engines for products and services fromother parties.

But, 10-15 years ago, this was all brand-new.

For me, it neatly partitioned my problem into two smaller problems:

How could I get my 1000-ish true fans?

What could I offer them that would be interesting for them yet profitable for me?

Finding the fans was all about reach. In particular, for somebody like me, it was all about reachto people in a particular interest area. Since I was considering doing something for iPhone orAndroid, I would need a way to reach people interested in iPhone or Android. I would need to be ableto offer that audience something free, to get my name out there. And, at the same time, sinceI suck at marketing, it would need to be powered by ���word of mouth��� more than banner ads orother forms of online marketing of that era. That took a bit to get established.

Fortunately, by this point, I already had a plan in mind for the second bullet, which I willtouch on in next week���s installment.