Winnyユーザーに逮捕者が出た時、Winnyの作者が家宅捜索を受けたため、Winnyの開発は事実上 停止した。 これを受けて、Winnyネットワークの将来に危機感を覚えたShareの作者によってShareの開発が開始され2004年1月5日に初めて公開された。
当時、Winnyの匿名性は絶対の信頼を得ており、逮捕者が出たことは利用者達に非常に大きな衝撃を与えた。そのため、利用者達の間では様々なテーマで多くの議論が行われ、また後継となるソフトが望まれていたこともあって、WinnyからShareに乗り換えるユーザーが多くいた。尚、当時はShareの他にFreenet+FrostやWinOZ（後に実在しないことが判明した。WinMX→Winnyの流れを汲むような名前だけが一人歩きしたものと思われる）が注目された。
Shareのバージョンについて、Ver1.0 CT (Connection Test Release) #1〜#21 → Ver1.0 DT (Diffuse Test) 1〜41 → Ver1.0 A (Alpha) 1〜82 → Ver1.0 EX (Extream) 1〜? と移り変わっている。UDP版では Ver1.0 NT (Net Test) 1〜5 となっている。
Shareは当初、正式名称が決まっておらず「Share(仮称)」と表記されていた。それがそのまま定着したため、Ver1.0 A75 以降は「Share」と表記するようになった。
当初はWinnyの後継を目指して開発されたShareであるが、Winnyネットワークが予想に反して現在も順調に稼働していることから、今では共存関係となっている。大容量のファイルの扱い・新しいファイルの素早い配布が得意なShareと、長期間の安定した配布が得意なWinnyの住み分けが行われている。また、ShareネットワークとWinnyネットワークとperfect darkネットワークの間でファイルの移植を行っている者がいる。
2005年2月23日に初めて公開されたUDP版は当初から余り普及せず、TCP版より遅れたまま更新が止まっている。しかし最近になって、プロバイダによる帯域制限を回避しやすいとの理由で一部の利用者達から見直されてきており情報交換が活発になってきている。現在、利用者が少ないことが原因である「赤スリ」（赤Sleep）に悩まされている。
Share作者は、法に抵触する利用は控えるようにと言っている。だが、違法な目的による利用者が大半を占めているのが現状である。
ShareはWinnyと同様に様々な理由で批判を集めている。
著作権法・わいせつ物頒布罪・児童ポルノ規制法・個人情報保護法等に抵触する違法なファイル共有が行われている。
非常に多くのインターネット帯域を消費している。
多くの情報漏洩を起こしている。
マスコミではこれらのうち情報漏洩に偏って報道される傾向にあり、特に昨今はウィルスによりプライベートなファイルや業務上保管していた秘密情報（個人情報や、自衛隊内部のPCの機密データ等）の流出問題に関する報道も多い。 （ただし、流出に関してはShare自体によるものではなくShareを利用するウィルスの所為によるものである。）
Shareは当初から一次配布ノードの保護も重点の一つとなっている。当時、一次配布ノードと監視ノードの直接接続が一次配布ノードの特定に繋がったと考えられていたため、それを阻止するために拡散アップロードを導入している。拡散アップロードについては中継も行うため、一次配布ノードと監視ノードが直接繋がることがあっても特定の決め手にはならない。ファイルの一次配布には主に拡散アップロードを用いるが通常のアップロードも利用できる。逆に二次配布に拡散アップロードを利用することもできる。
ファイルのハッシュ値やID（トリップキー）はSHA-1により生成される。IDは電子署名技術を用いているため、偽装は困難となっている。
Winnyの通信の暗号が解読されたのを受け、Shareでは通信の暗号化が強化されている。1024ビットRSAとRC6が利用されている。
Shareの暗号通信は安全と思われていたが、ネットエージェントのOnePointWall等により解析可能になったほか、2007年1月に解析されたプロトコルが公開されたため、暗号化に関してWinny同様に疑問が生じた。
ただしWinnyと同様に、通信路の暗号化は大して重要ではない。拡散アップロードという手法が使われるため、一次配布ノードの特定はWinnyより難しいと考えられる。
逆に、Shareは二次配布の時は中継をしないため二次配布ノードの匿名性はWinnyよりも不利となっている。現在では、Sharebotによって二次配布ノードの特定は可能となっている。
2007年3月に、Shareネットワークにおけるファイルの所有者を特定するツールSharebotが住商情報システムにより一般向けに公開された。社会問題と化している情報流出対策を目的としている。
Sharebotを利用する場合の注意点として、Sharebotは Share ver1.0 EX2 本体を要求するがそれを書き換えてしまうため、Share.exeはコピーしておく必要がある。
SharebotがCompleteキャッシュのみを収集する性質から、当初は一次配布ノードの絞り込み・あるいは特定の可能性が探られた。なぜなら、ネットワーク上で最初にCompleteキャッシュを持っているのは一次配布ノードなので、最初に観測されたノードが一次配布ノードである可能性が高いと考えられたからである。しかし、幾つかの理由で、一次配布ノードより先に二次配布ノードが観測される可能性が高いため、特定に至らないと今の所は考えられている。また、同様の理由で、観測された二次配布ノードが自分の意思でダウンロードしたとは限らないとも考えられている。
詳細は不明であるが、Diffuseキャッシュを持つノードはたまにCompleteキャッシュとして他のノードに報告する。
約10MiB以下のファイルのDiffuseキャッシュは、ほとんどが完全なものとなり常にCompleteキャッシュとして他のノードに報告する。
拡散アップロード中は該当するファイルの存在を他のノードに報告しない。
上記のShareの性質を利用してSharebotによる観測を回避する方法が考案されている。
DiffusionProCloneの設定を以下のように変更。
「他のクエリがアクティブな場合、一時停止」をオフに。
「アップロードキュー監視間隔」をなるべく短く。(100ms)
「アップロード登録を厳密にチェック」を有効に「アップロード後、元のクエリに復帰」を無効にした上で「クエリ検索に費やす最長時間」を最適値に。最適値は""で囲ったファイル名で検索をかけて表示されるmsec値より若干大きめの値を設定する。（環境によるが300ms以下）
一次配布するファイル以外のキャッシュも多く持っておく。
一次配布するファイルをアップロードフォルダに入れて「クイックチェック」を押すと、自動的に拡散アップロードが開始される。万全を期すなら、通信を停止した状態で、同様の作業を行い手動で拡散アップロードに登録してから、通信を再開する。
自分のノードの周りにCompleteキャッシュの保持を報告するノードが現れると、自動的に拡散アップロードは終了する。
また以下の回避方法も考案されている。
一次配布するファイルAを関係の無いファイル名Bに変更してからアップロードフォルダに入れて「クイックチェック」を押す。
BをDiffusionProCloneを利用する等して通常通り拡散アップロードを繰り返す。
Bをアップロードフォルダから外し「クイックチェック」を押し、Bをデータベースから削除し、「ファイル数」が減らなくなるまで「未使用削除」を繰り返し押す。
通信を停止する。
Bのファイル名をAに戻し、Aをアップロードフォルダに入れて「クイックチェック」を押す。
Aをアップロードフォルダから外し「クイックチェック」を押す。
通信を再開する。
データベースを含めてAを検索し、Aをダウンロードに登録する。
Aのダウンロードを完了するまえにダウンロードを停止させる。
ファイル名Bは流通の成否に直結するため慎重に決める必要がある。