Web サービスを開発し運営が上手く行っていたとしても問題があります。 JavaScript はクライアント側で実行されるスクリプトなので 全てのソースコードが容易に読まれてしまう点です。 圧縮や難読化を施して読みにくくしたところで 理解にかかる時間が少し増えるだけでしょう。 例えば企業が多数の開発者を投入したりすれば 短時間でクローンを製造することさえ可能です。
もちろんサーバ側での処理については公開しないことが出来ますが、 その処理が大きいほど運営コストが増すことでしょう。 クライアント側で動かすにしても企業秘密に近い部分には Java Applet や ActiveX などの非スクリプトを使うことも出来ますが、 複数の言語を利用すれば開発コストが嵩むことでしょう。 また Java には逆コンパイルされる恐れもあります。 ソフトウェアの面では先行者が圧倒的に不利なのです。
逆に先行者の強みは利用者とデータの蓄積にあります。 特に Consumer Generated Media(CGM) においては 利用者が多いほどデータの蓄積が速くなり データが蓄積されるほど利用者が増えるという強い相関があります。 他のサービスに真似されるよりも先に十分な蓄積を得ていれば そう簡単に追いつかれることはないはずです。
Web 2.0 のサービスではベータ版のまま運営している例が多いです。 ベータ版とはまだ完成していない試用版という意味であり 正式なサービスとするほどの信頼性を持たないものです。 それでも公開するのは利用者層を確保するとともに 利用者からの要望を吸収して完成度を上げていくためです。 例えば mixi は株式上場しても未だにベータ版です。 今後もずっとベータ版のままなのではないでしょうか。
またWeb サービスが蓄積したデータを オープンにするべきかという問題もあります。 データをオープンにするというのは Web API を公開して外部利用を許したり、 データのインポート・エクスポートを許したりといったことです。 最近の大規模なデータベース・サービスでは Web API を公開しているところが多いようですが、 CGM サービスは大規模なものであっても インポート・エクスポートが出来ないところが多いです。
特に極端なのが Social Network Service(SNS) で Web API もインポート・エクスポートもないところがほとんどです。 ブログでも初心者層を狙っているところほど Web API もインポート・エクスポートもないことが多い気がします。 これは初心者はそもそも囲い込みに気付かないのに対して コンピュータに慣れている人は囲い込まれない自由を求める ということなのではないでしょうか。 本当の上級者は初めから自分のサーバで活動するのかもしれませんが。
好むと好まざるとに関わらず ソフトウェアについては公開が進んでいます。 逆にデータについては囲い込みが進んでいるように思います。 提供者としては囲い込んだ方が利益に結び付けやすいが 利用者としては囲い込まれない方が便利だ という均衡が今の状況なのかもしれません。