これは、プロジェクトが2013年1月2日に発表されたときのUbuntu Touchの外観です。 画像:Canonical
Ubuntuの携帯電話やタブレットはもうないので、プロジェクトが失敗した理由と、これから学べることを教えてください。
プロジェクトへの参加をまとめると、2013年の発表の瞬間から2014年12月まで、Nexus 7でUbuntu Touchを絶えず定期的に使用し、2014年12月にClickアプリケーションの作業を開始し、15部から記事を書き始めました。 2015年1月のシステムデバイスに関するUbuntu Touchのハッキングは、Ubuntu Phone Insiderプログラムのインサイダーであり、Canonical Meizu MX4を受け取り、 UbuContestアプリケーション開発者向けのコンテストを組織し 、スポンサーし、2016年4月頃までバグレポートとアプリケーションに取り組みました残りのすべてのデバイスを販売または再取得しました 2016年半ばの物件。 それで、私はプロジェクト、その問題、そして私たちがどこでより良く働くことができるかについて、いくつかの考えを共有できると思います。
この記事は、携帯電話、Unity 8、およびその他のコンポーネントのオペレーティングシステムで実行され続けるUBPortsプロジェクトには影響しないことに注意してください。
1.彼は有益なニッチに落ちなかった
PC、ラップトップ、サーバー向けのUbuntuにより、これは比較的簡単になりました。 これらのデバイスのほとんどすべてで、ハードウェアで動作するオペレーティングシステムをインストールできるため、2004年にUbuntuが登場したとき、最大のライバル(Microsoft)は非常に脆弱でした。 Windowsは評判が悪く、価格が高く、このシステムは豚肉を食べるリソースだったので、Ubuntuは煩わしさを抑え、安く、インストールしやすく、古いコンピューターでより良く動作する必要がありました。 それがまさに彼女がしたことです。 Windowsは今でも評判が悪く、今でもユーザーをスパイしていますが、それでもかなり高価です。 そのため、Ubuntu Desktopは必要ありませんでした。ユーザーの視聴者を節約し、増やすために今すぐ行う必要はありません。
Windowsのサーバー市場では、Red Hatと特にSUSEは保守的なソリューションであり、あまりにも不器用で高価すぎると考えられていました。 Red Hat Enterpriseのサブスクリプションには年間数百ドルの費用がかかります。このサブスクリプションには、実際の人間によるサポートも含まれていません。 いくつかの業界サポートとリポジトリ内の膨大な量のパッケージを備えた、急成長している安価な代替品は、特にクラウドソリューションの場合、多くの人にとって興味深いものでした。 UbuntuがOpenStackのモデルオペレーティングシステムとして選択されたという事実も非常に役立ちました。
しかし、モバイルデバイスでは、すべてが異なります。 携帯電話やタブレットのオペレーティングシステムをフラッシュすることはできません。 各デバイスには、カスタムの特別に準備されたAndroidビルドが付属しています。 Ubuntuが2013年にモバイル市場への参入を発表したとき、デスクトップ市場の状況とは異なり、AndroidもiOSも脆弱ではありませんでした。 人々は、AndroidとiOSの評判が悪かったり制限があったり、使用するのが不便だったりするのではなく、Googleの独占を(当然)恐れているため、3番目の選択肢を求めました。 そのため、AndroidおよびiOSに対する攻撃は、デスクトップおよびサーバー市場のMicrosoftやRed Hatほど簡単ではありませんでした。
Canonicalの1人は、プロジェクトがそれ自体をサポートするためにモバイル市場の約1%を獲得する必要があると言ったのを覚えています。 当時、これは年間約1100万台のUbuntuスマートフォンと数百万台のタブレットを販売することを意味していました。 各デバイスのソフトウェアとサービスで少なくとも1ドル/ユーロを稼ぐことができた場合、100人以上の開発者の労力を簡単に支払っていたでしょう。正しく使用すれば、これは大金になります。 Sailfish OSを開発しているJollaには、ある時点で約120人の従業員がいたと思いますが、Canonicalがすでに持っているマーケティングおよびサポート部門があったと思います。 しかし、Ubuntu Desktopユーザーの数が2,000万〜3,000万人の地域にいることを考えると、年間1,100万台の電話と数百万台のタブレットを販売することは非常に野心的な目標でした。
- 1パーセントを達成する機会番号1。 競合他社よりもはるかに優れているため、標準になり、1%でも心配する必要はありません。 これは不可能であることがわかっていたと思います。特に、すべての重要なサービス(WhatsApp、Google、Twitter、Instagramなど)がUbuntuデバイスで実行するアプリケーションを複製することさえ許可しなかったことが明らかになりました。 Canonicalは独自のTelegramクライアントを作成しませんでした。最初のUbuntu商用電話が市場に参入したとき、メッセンジャーはまったくいませんでした。 そして、これは2015年で、全員がテキストメッセージを絶えず交換しています。 「開発者向けのデバイス」として位置付けられていても、同じAndroidモデルと同じことができない場合、Ubuntuの携帯電話に同じお金を払うことを望みませんでした。
- 1パーセントを達成する機会番号2。 深いポケットのあるニッチに配置します。 Canonicalは「収束」ニッチに集中しすぎており、多くの人にとっては面白くありませんでしたが、同時に、Microsoft、Google、NSAからの監視に満ちたすべてのハッカー、メーカー、および人々を無視しました。 外部ディスプレイに接続すると、速度が遅くなるラップトップになる可能性のある電話機にプレミアム価格を支払う意思のある人はほとんどいませんでしたが、 Blackphoneにプレミアム価格を払う意思のある人はほとんどいませんでした 。
2.ユーザーへの不便および優先順位のゆがみ
私は正直に言いたい:最初のいくつかの無線(OTA)の更新を受け取った後、私は自分自身に尋ねました:「bqとMeizu、特にユーザーはこれに耐えますか?」 Meizu MX4は過熱していました。 バッテリーインジケータは、しばしば誤ったデータを示しました。 モバイルデータは確実に機能しませんでした。(国内)ローミングはまったく機能しませんでした。 位置情報サービスは非常に信頼できませんでした。 電話が着信したとき、またはUIがボタンを隠したために発信できないとき、電話は常に信号を発しませんでした。 目覚まし時計に頼ることは不可能でした。 Bluetoothは、オーディオデバイスとそれ以降の入力デバイスのみをサポートしましたが、基本的な形式であってもファイル転送はサポートしていませんでした。 5回目のOTA-5更新まで、WiFiはWPA Enterpriseネットワークに接続できませんでした。 ある時点で、オーディオプレーヤーがファイルのインデックス作成の過程でファイルを削除し始めたようです。 などなど。
動作するはずだったが動作しなかったもののリストは非常に長い。 さらに悪いことに、リグレッションのように、いくつかのOTAアップデートを通じてバグが何度も戻ってきました。 電話/タブレット用のプロジェクトが存在する間、Launchpadのバグレポートの数は、私が前に見たことがなかったように急増しました。
これらすべてのバグの根絶は最優先事項ではなく、開発者はより多くの鉄(Meizu Pro 5、bq Aquaris 10)のサポートと収束の確保に多くの時間を費やしました。 プロジェクトの最終日まで、私が話したユーザーはデバイスに満足していませんでした。 デバイスは充電せずに数日間機能したため、データ転送機能をオンにせず、2日間で1回電話をかけなかった父のように、最も基本的な機能を使用した人だけが満足しました。 ただし、スマートフォンを150ユーロで購入し、それを「スマート」にする機能を使用しないのはあまり意味がありません。
収束がどのように見えるはずでしたか。 画像:Canonical
すべてをすぐに修正するのに十分な開発者がいないことを理解していますが、良い電話や収束の良いタブレットを作る代わりに、本当に何もできないデバイスを手に入れました。 プロジェクト全体には、一種のハローが常に付随していました。「これらは開発者向けのデバイスです。すべてを迅速に修正する必要はありません。長距離を勝ち取ります」 その後、彼らは損失を減らし始め、2016年10月に主要な開発者全員をSnappyに移し、電話とタブレットが静かに死ぬことを許可し、数か月の間、何も言わなかった。
はい、そしてデザイナーはスコープのアイディアをあまりにも長い間保持していたと思います。 特に、デスクトップでこれらのスコープを使用する方法を誰も実際に理解できないという事実を考慮してください。
3.デバイスは入手が難しく、時代遅れでした
デバイスを実際に入手するのが難しすぎるということは、私たち全員が同意できると思います。 私は店で最初のNexus 7とeBayでNexus 4を購入しましたが、プロジェクトが本当に深刻なペースになったとき、これらのデバイスはすでに古くなっていて、入手するのが難しくなり、すぐに公式のイメージビルドが出なくなりました。 少なくともbqデバイスはヨーロッパ全土で販売されましたが、ほとんどの場合、ページ上で「在庫なし」とマークされていました。 MX4を入手することは、Ubuntu Phone Insidersプログラムに参加していない人にとってはほぼ不可能でした。 アメリカの人々がなんとかそれを手に入れることができたとしても、彼はモバイルネットワークにフルスピードで接続しませんでした。
2015年と2016年のほとんどで、アプリケーション開発者がアプリケーションをテストするために公式にサポートされているデバイスを望んでいた場合、私は何を推奨すべきかわかりませんでした。
一方、ほとんどが待ち望んでいたデバイス-並外れて高性能なUbuntu Edge-は異なることが判明しました。 bqデバイスは安価で、少量の内部メモリがあり、3Gサポートしかありませんでした。 MX4には大画面、高速、4Gが搭載されていましたが、SDカードスロットさえありませんでした。 コンバージェンスに必要なHDMI出力は、すべての公式電話で利用できるわけではなく、Miracast / Aethercastは同等の代替品ではありませんでした。 UbuntuはAquaris E4.5 / E5のFMラジオなど、ハードウェアの可能性をすべて明らかにすると考えていましたが、これは計画されておらず、Androidのドライバーがなければ、そのような機能を追加することはほとんど不可能でした。
また、多くの人は、UbuntuスマートフォンがAndroidよりも本質的に安全であると予想していました。これは、オープンソースで頻繁に更新されるためです。 明らかに、これはそうではありませんでした。モバイルトランスミッター用のAndroidドライバーとソフトウェアは、ハードウェアへのフルアクセスを持ちながら、依然として独自仕様で安全ではありませんでした。 これを知っている人はほとんどいませんでした。
4.コミュニケーションとマーケティングはより混oticとしており、時々誤解を招く
私は毎日開発に追いつくために膨大な時間を費やしましたが、通常、次のOTAに何が表示され、何が削除されるのかさえ知りませんでした。 メーリングリスト、IRC、電報チャンネル、Launchpad、公式ウェブサイト、開発者間のプライベートな会話、スプリント、Ubuntu Online Summit-あまりにも多すぎました。 そして、アナウンス時に最大のメディア報道を保証するために、彼らがニュースを秘密にしたかったとき、これはCanonicalのすべての秘密の会話にさえ言及していません。
Canonicalの従業員の多くは自宅やさまざまなタイムゾーンで働いているため、私にとっては状況がさらに悪くなりました。 「電源ボタンを押すと、電話は1秒後にしか起動しません」と「不正なバッテリーインジケーター」のバグを解決しようとしたことを覚えています。 唯一の信頼できる場所はLaunchpadだったので、人々はそれに頼っていました。 ただし、バグレポートに価値のあるものを投稿する1分前に相手に話しかけたり、問題に対処する方法を決定したりする方が効率的な場合もあります。
カーネルソースの作業をしている人は、アジアのどこかにいるかもしれません。 すべてのQ&Aを担当する人は、米国のどこかにいるかもしれません。 私はヨーロッパに行ったことがあります。 実際の作業時間は特に重複していません。 そのため、ある日、朝の8時から仕事を辞めるまでアジアの人と話をし、その後正午または夜に仕事の日が始まるアメリカ人の人と話をしなければなりませんでした。
bq Aquaris E4.5 Ubuntu Editionの広告機能。 「収束」という言葉、HDMI、FMラジオなど、人々が期待していた他の多くの言葉の欠如に注意してください。しかし、マーケティングはそれを与えませんでした。 画像:bq
特に「期待と現実」に関して、マーケティング部門から多くを学んだと言わざるを得ません。 たとえば、多くの人はAquaris E4.5 / E5およびMX4が後のOTAアップデートでコンバージェンス機能を取得することを当然のことと考えていましたが、メーカーやCanonicalはデバイスの販売時にこれを約束しませんでした。 プロジェクトがキャンセルされるまで、ほとんどの人はデスクトップ(Firefox、SIPクライアントなど)と同じアプリケーションを実行し、apt-getを使用してアプリケーションを管理できると考えていました。 。 「これは同じUbuntuです」という事実を強調しすぎましたが、実際はそうではありません。 Firefoxが起動せず、apt-getがすべてを壊すことを、さまざまなサポートチャンネルのランダムな人々に説明しなければならなかった頻度を思い出せません。 多くの場合、モバイル向けUbuntuが非常に異なることを知って非常に驚きました。
5.ユーザーもアプリケーション開発者も必要としない技術的機能を重視しすぎています。
新しい独立したモバイルオペレーティングシステムの発表は、アーキテクトが「はい、それをやろうが、それを正しい方法でやろう、そして私たちは他のものよりも良くなる」と言う正当な理由になったと感じています。 Ubuntuは、グラフィカルユーザーインターフェイスだけでなく、すべてのデバイスおよびあらゆるフォームファクターで機能するインターフェイスを提供することになっています。 LinuxおよびAndroidカーネルのようにアプリケーションを相互に分離するだけでなく、データとプライバシー保護を備えた本格的なサンドボックスを実装します。 彼女は魔法のように、実行中のアプリケーションがバッテリー電力を消費しないようにします。 などなど。 技術的な面で他の人が何をするにしても、Ubuntuはより良い、よりエレガントな方法を行う必要があります。
このすべてが私にとって理にかなっているわけではありません。 Unity 7はCompizに依存しており、ロータリーディスプレイなどのさまざまなフォームファクターでの作業に適していないため、Unity 8のリリースが必要でした。しかし、Mirにとって唯一のことはX.OrgとSurfaceFlingerを置き換えることでした。デスクトップとモバイルデバイスで単一のAPIを使用できます。 私はグラフィックテクノロジーとAPIの専門家ではありませんが、少なくとも「手が足りない」という観点からは、誰も使いたくない、既存の代替品と比較して特別なものを追加しない、まったく新しいグラフィックサーバーを開発しているようですどうしても避けるべきものです。 特に、ユーザーに違いが見られない場合。 Ubuntu Touchは、2013年末まで静かにAndroid SurfaceFlingerを使用していました。
私の意見では、分離モデルとライフサイクルにも同じことが当てはまります。 バッテリーを少し節約できるように設計を複雑にし、この複雑さによりシステムサービスの実装に多くの追加作業が必要になりますが、開発チームが小さすぎるため、これらのサービスが実現されない場合、ユーザーとアプリケーション開発者はもう少し長い間あなたを称賛します。 むしろ、彼らは不足しているものについて無限に不平を言うでしょう。 そのため、 バグレポート 「優先度の高いバックグラウンドサービスの実装を終了する」が最大240度まで温まりました。プロジェクトの発表から3年が経過しましたが、実際には何も行われていません。
別の良い例は、計画されたメッセージフレームワークです。 Jabber / XMPP、SMS、Telegram、WhatsAppのいずれであっても、すべてのタイプのメッセージに対して1つのシステムアプリケーションを取得する必要があり、サードパーティのサービスがプロトコルのプラグインをリリースできました。 このフレームワークは、アプリケーションがバックグラウンドで実行されることを禁止された主な理由の1つでした。 したがって、バックグラウンドでメッセージを受信するXMPPクライアントを個別に作成することはできません。 しかし、あなたがプラグインをリリースすることになっていたメッセージフレームワークは遅れ、結果として決して出ませんでした。 CanonicalはTelegram開発者にサーバーコード(!)を変更してUbuntu Push Notificationサービスをサポートするように説得したため、Telegramクライアントはバックグラウンドで動作できず、ポップアップメッセージのみを表示できました。
一部のCanonicalの主要な開発者は、Ubuntuは非常に重要であると考えていたため、すべてのサービスプロバイダーがサーバーコードを変更してUbuntuプッシュ通知をサポートし、問題を解決しました。 Telegram以外は誰も考えていませんでした。
(ちなみに、私はライフサイクルモデルがバッテリーの顕著な節約につながらないと考え続けています。それについて考えれば、常に同じ、そしてより多くのCPUサイクルを使用します)。
6.アプリケーション開発者の生活は複雑すぎた
最新のモバイルOSはOSだけではありません。 これはエコシステムです。 そして、ここでUbuntuが最も失敗しました。
Ubuntu for mobileは、それ以前のプログラム実行環境と基本的に互換性がありませんでした。 彼女は、Android、Windows、X11、またはiOSアプリケーションを実行できませんでした。 Android、Windows、X11、またはiOSアプリケーションを再コンパイルすることはできませんでした。 グラフィックシステム、システムサービス、サンドボックス、一連の基本ライブラリ-すべてが異なっていました。 Ubuntu Desktopとは完全に異なっていました。 何日も「これは同じUbuntuです」と言うことができますが、デスクトップでMirが実行されないためにアプリケーションをテストすることさえできない場合、これは同じUbuntuではなく、2つの異なるプラットフォーム用に開発する必要があります。
Canonicalが登場し、SDK全体、Qt Creatorに基づく統合開発環境、クロスコンパイル環境、およびまったく新しいUbuntu QMLコンポーネントセットを作成しました。 私は本当にここで誰かを怒らせたくありませんが、既存のコードを使用しないことに加えて、これがどのように行われたかは非常に混乱し、アプリケーション開発者にとっては失望でした。 何も機能せず、すべてが変化し、絶えず壊れていました。 SDKが数週間壊れている場合があります。 バージョン管理スキームは登場しましたが、アプリケーションはまだ動作しませんでした。
OSが以前と同じレベルの互換性を示していたにもかかわらず、OTAが更新されたMirクライアントライブラリをリリースしたため、ある時点でディレクトリ内のglmark2アプリケーションを再構築および更新する必要がありました。 その後、バージョン管理スキームによって、アプリケーションを記述する公式の方法が確実に機能することが保証されますが、公式の方法はQMLとHTML5だけであることが明らかになりました。 Glmark2は、他の多くの製品(SDLを使用するゲームなど)と同様に、Mirと直接対話しました。 ディレクトリ内のアプリケーションは、各OTAの後にそれらをチェックおよび更新しないと、単に動作を停止する可能性があります。 古いAndroidアプリケーションを最新のAndroidスマートフォンで実行することはできますが、昨年のClickアプリケーションは、常に監視しないと次のOTAの後に動作しなくなる可能性があります。 2015年末のIRCでの活発な議論を覚えています。その間、複数のCanonical開発者がこの事実に戸惑い、SDKチームに、そのような状況でアプリケーション開発者がどのように働くかを尋ねました。
Click Storeにある私のアプリの1つであるPanda Loveでbq Aquaris E4.5をレンダリングする
私はアプリケーション開発者として始めました。 やりたいことは何でも、ほとんどゼロから始めなければなりませんでした。 GUIを作成しますか? Ubuntu QMLのコンポーネントでサポートされているのはQMLのみであり、QMLは既存の多くのコードと優れたツールを備えた確立されたエコシステムとは言えません。 既存のUIライブラリのいずれかを使用するだけですか? それらはすべてX11または多分Waylandで動作するように設計されており、SDLや他の人がMirのバックエンドを取得するまでに多くの時間が経ちました。 ハードウェアおよびシステムサービスとの通信? サンドボックスのため、D-Busを介してUbuntuの専用サービスに直接アクセスすることは困難でした。NetworkManagerなどの「標準」プロセスのほとんどは、サンドボックス内からアクセスできませんでした。 バックグラウンドで何かをダウンロードしますか? これを行うには、特別なUbuntuダウンロードマネージャーに連絡してください。 電話以外のイベントに関する通知を受け取りますか? すべてをUbuntuプッシュ通知サービスと統合する場合のみ。
そのため、最も基本的なシステムで作業を開始する必要がありました。 その後、2015年1月にWiFiスキャナーとBluetoothスキャナーを作成したかったのですが、必要なAPIとシステムサービスがすべて存在していませんでした。 欠落しているAPIとシステムサービスの多くは登場しませんでした。
これにより、ほとんどのサードパーティ開発者にとってプラットフォームは非常に魅力的ではありませんでした。 彼らは、特に小規模なユーザーベースを考慮して、アプリケーションの別のバージョンをゼロから作成するための投資がどのように報われるかを見ていませんでした。 「元の」開発者がClick Storeにダウンロードする単一のアプリケーションを覚えていません。 Telegramクライアントでさえ、Canonical自体によって開発されました。
私たちの多くは、単純なWebアプリケーションを作成するか、既存のアプリケーションを複製しました。 そしてすぐに、多くのアプリケーションが非常に不利な利用条件である種の独自のオンラインサービスに依存するという問題に直面しました。 個人的には、ドイツ鉄道ナビゲーターのクローンであるBDナビゲーターを開発しました。 クライアントサーバープロトコルをリバースエンジニアリングして、実際の列車のチケットを購入する以外はほとんどすべてをコピーできるようにしましたが、暗号の小さな断片を埋め込み、ドイツで盗まれた暗号キーを使用することは違法です。 私はドイツ鉄道に許可を求めましたが、彼らは拒否しました。 最終的に、アプリケーション全体が、モバイルWebページにブックマークを付けた荘厳なWebコンテナーのレベルまで低下しました。
WhatsApp、Twitter、Instagram、Google Plus、Google Driveなどでもまったく同じことが言えます。 多くのことをコピーできますが、サービスプロバイダーはこれを許可していません。 WhatsAppは、本格的なクライアントの開発ではなく、単にAPIへのアクセスのために7桁の合計を要求したと言われています。 InstagramはAPIを閉じたため、組み込みのInstagram Scopeも削除する必要がありました。 多くのサービスでは、GoogleにはパブリックAPIがありません。
(また、少数のオープンソースのオタクは、すべての一般的なアプリケーションのクローンの最新コレクションを維持することはできません。スケールしません。)
7.彼女はそれほどオープンではなく、意図したような公的な支援を享受していませんでした。
今、私はこの声明が矛盾している可能性があることを理解し、同意しない場合は、これは単に私の気持ちであることに留意してください。 たぶん私は少数派です。 わからない。
モバイル向けのUbuntuは「通常の」Ubuntuと同じくらいオープンであるはずでしたが、それは起こりませんでした。
- 私たちが開発したすべてのソースコードは、不明な数のLaunchpadプロジェクトに分散されていました。
- GitHubカーネルソースはしばしば非推奨になりました。
- すべてのプロプライエタリなAndroidドライバーと他のソフトウェアのコードは、Canonicalの従業員のみが利用できました。
- Canonicalとその商用パートナーには、プライベートバグレポートがある完全にプライベートなLaunchpadゾーンがありました。 多くの場合、公開バグレポートにはプライベートページへのリンクがあるため、情報は半分しかありませんでした。
- , paste.ubuntu.com .
- , , Launchpad Canonical . , Aethercast .
- Canonical, , , .
- , , Canonical. , , .
- , - , OTA. - Launchpad .
よくある質問
, .
?
, Nexus 7, Nexus 4, bq Aquaris E4.5 Mediatek ( -) Ubuntu. MX4 Canonical. , - .
- ?
はい - , , Canonical 30% .
, ?
いや
, ?
, 2015 . , , WhatsApp, Twitter , «» . , bq Aquaris M10.
, , , . API , , . , , , . , , .
2016-, . なんで?
, . ó , , , .
, , . « , », . , .