Metasploit As Case Study In Selling a FOSS Project 50
coondoggie sends in a Network World interview with HD Moore on the occasion of the commercial release of Metasploit by Rapid7, the company that bought it half a year ago. The pseudonomous author uses the occasion to explore the question of what happens to a vital open source project once it is sold commercially. "Metasploit might become one of the first examples of how a completely FOSS project grows up to be successful. It is the venture capital model without the startup money (though VCs are funding plenty of OS startups these days, too). Build it. They will come. Someone will buy it. And if you want them to stay, the FOSS project better remain as well supported as the eventual commercial version. This isn't the first open source project to have been bought by a big guy. And the jury is still out on on most of them. I could argue that Metasploit is a bit unique in that it didn't have a commercial arm when Rapid7 acquired it. That could not be said about SUSE or MySQL or even Gluecode (bought by IBM), etc."
Re:a sad story (Score:3, Informative)
HDM ended support for the GTK and web interfaces when he was purchased. Now, you need to purchase Metasploit Express ( http://www.metasploit.com/express/ [metasploit.com] ) to get a graphical interface for Metasploit.
Re:a sad story (Score:4, Informative)
Not quite - Prior to the 3.2 release, both the main developer for msfweb and the main developer for msfgui dropped out of the project (LMH and Fabrice); We fixed these interfaces up just enough to make them work for 3.2, but they have always been incredibly buggy and crash-prone. The msfweb interface needs an overhaul to be really usable (and we would love for someone in the community to take this on), however the msfgui interface will have to be rewritten from the ground up due to an insane number of crash bugs in the ruby-gnome2 codebase. As the project moved towards 1.9 compatibility, both msfweb and msfgui fell even further behind. We deprecated these interfaces in 3.3, which was immediately after the acquisition, but the acquisition had little to do with the decision to stop trying to maintain these. The main goal of msfweb and msfgui was to support an interactive console on the Windows platform; since we added RXVT/Cygwin to the 3.3.x packaging, it became possible to run msfconsole natively, removing the need to keep hacking msfweb/msfgui to work. The decision really came down to msfweb vs cygwin; with msfgui no longer an option due to the aforementioned crash bugs.
Long-term, we are trying to consolidate all of the interaction into a small number of tools; currently we have msfconsole, msfcli, msfweb, msfgui, msfrpc, and then msfencode+msfpayload. We would like to merge the cli functionality into the console (its buggy with certain module types at the moment), remove msfweb and msfgui until we find a new owner in the community, make msfrpc the standard way to programmatically interact with the framework, and combine msfpayload/msfencode into a single utility.