Eclipse MylynプロジェクトがApplication Lifecycle Management toolsという旗印のもと、トップレベルEclipseプロジェクトに昇格した（Mylynという名前は短い名前として残される）。プロジェクト憲章には、エコシステムにおけるその目的が説明されている。
平均的なEclipse Mylynユーザにとって、これは（直接的には）ほとんど何の意味もない。Mylynは以前と同じコミッタによって開発され、現在と同様の開発者視点の体験を提供するだろう。実際にEclipseのトップレベルプロジェクトになるということは、今やEclipseの時代錯誤なプロジェクト構造のしるしでしかない。Eclipseではプロジェクトの組織構成を2つのレベルに強いている。JDTやPDEのようなEclipseプロジェクトと、CDTやPDTといったToolsプロジェクトだ。
Mylynは自分の居場所を見つけるのに多少時間がかかった。インキュベーションフェーズからTechnologyプロジェクト、そしてToolsプロジェクトを経て、ようやくトップレベルにある最終的な場所へと到達した。（大部分のプロジェクトはTechnologyプロジェクトかToolsプロジェクトのどちらかだ。そして、どちらにするかは自由で、ほとんどの場合、そのプロジェクトのユーザやコミッタにはまったく見えない）。こうした分割は主にCVSおよびSVNルートに基づいている。プロジェクトがGitに移行して、リポジトリ構造を強いる足かせがなくなると、これは意味をなくすだろう。
再構成作業の一部として、Mylynは自身のセカンドレベルプロジェクトをいくつか作成している。これは実のところ既存のMylynモジュールを再分割しただけであり、EGitとCVSコネクタをMylyn/SCMプロジェクトの一部に、BugzillaとTracコネクタをMylyn/Tasksプロジェクトの一部に、そして、Mylynの当初の人気をもたらしたアクティブUIフィルタリングの土台となるものをMylyn/Contextプロジェクトにした。
Mylynはずっと変化がなかったわけではなく、どんどん多様化している。Mylyn WikiTextコンポーネントはもともと簡単にバグレポートを書くためのものだったが、独立したMylyn/Docsプロジェクトにスピンオフして、RichTextをベースとする編集機能と一緒にやっていくことになった。また、Mylynはその領域をHudsonとの統合にまで拡大している。これには、コンソール出力の読み込み機能や、（ローカルでやるのと同じくらい簡単できるよう）サーバ上で失敗したテストにフックする機能などが含まれる。
最終的に、Mylynは自らのゴールをレビューベースのシステムに対するインターフェイスを提供することに置いており、シンプルなMylyn Taskに基づくレビューシステムを提供すること、そして、既存のレビューシステムにフックすることを最初の計画として立てている。
詳しくはMik Kersten氏とのインタビューやプロジェクト憲章を読んでみよう。