アカウント名:
パスワード:
A社があるサービスを作る。A社のサービスが広まって人気を獲得。↓B社がA社のサービスをまねる。データのやりとり方式（API）は丸々ぱくるA社のユーザーは何の修正もなしに簡単にデータ移行できてB社に乗り換えれる。ぱくりだから開発時間もすくなく低価格サービスでシェアを伸ばす
APIを保護しないというのはこういうことだからね。B社にとってみればありがたいけど、A社にしてみればたまったものじゃない。そりゃパクれれば発展に寄与するかもしれないけどさｗ
A社がぱくられたくないときは権利を主張する。A社が社会に貢献したいと思うならオープンにする。作った側が選択ができるように保護の仕組みは合ったほうがいいよ。
ぱくりだから開発時間もすくなく
この話題のたびにつっこみがあるけど、APIの話と実装の話は区別してよ
既にできているものを真似て実装するのは、ゼロから開発するよりも容易だよ。特に完成形が見えてると仕様作るのが楽。
単に「似たようなものが欲しい」だけなら、設計の手間が減らせるのは大きなメリットだけど、「互換環境が欲しい」だと、アンドキュメントな仕様とかバグ挙動とかまで再現する必要があって、実装とテストが茨の道。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
パクられ側からすればたまったものじゃない (スコア:0, 参考になる)
A社があるサービスを作る。A社のサービスが広まって人気を獲得。
↓
B社がA社のサービスをまねる。データのやりとり方式（API）は丸々ぱくる
A社のユーザーは何の修正もなしに簡単にデータ移行できてB社に乗り換えれる。ぱくりだから開発時間もすくなく低価格サービスでシェアを伸ばす
APIを保護しないというのはこういうことだからね。
B社にとってみればありがたいけど、A社にしてみればたまったものじゃない。そりゃパクれれば発展に寄与するかもしれないけどさｗ
A社がぱくられたくないときは権利を主張する。
A社が社会に貢献したいと思うならオープンにする。
作った側が選択ができるように保護の仕組みは合ったほうがいいよ。
Re: (スコア:0)
ぱくりだから開発時間もすくなく
この話題のたびにつっこみがあるけど、APIの話と実装の話は区別してよ
Re: (スコア:0)
既にできているものを真似て実装するのは、ゼロから開発するよりも容易だよ。特に完成形が見えてると仕様作るのが楽。
Re:パクられ側からすればたまったものじゃない (スコア:0)
単に「似たようなものが欲しい」だけなら、設計の手間が減らせるのは大きなメリットだけど、
「互換環境が欲しい」だと、アンドキュメントな仕様とかバグ挙動とかまで再現する必要があって、実装とテストが茨の道。