Snort mailing list archives
Re: RFC: Forking Snort
From: Erek Adams <erek () theadamsfamily net>
Date: Tue, 2 Jul 2002 11:28:36 -0700 (PDT)
Comments inline... On Tue, 2 Jul 2002, Jed Pickel wrote: [...snip...]
Snort has come to a critical point in its evolution. Due to the hard work from numerous developers and thousands of users, Snort is now monitoring many of the worlds most sensitive networks. Also, a growing number of companies are offering commercial solutions based on Snort and standardization efforts have leveraged Snort as a conduit toward furthering security standards. As a result, the number of Snort users continues to grow as it becomes more commercially accepted.
I agree that the number of snort users is a rapidly rising number. I don't think it's from 'commerical solutions based on Snort and standardization efforts'. I think the fact that you can now have commercial support and training has been the big seller. Management wants to have someone to 'blame' if something breaks. Now with a commercial support and training team, the managers have that.
Few would disagree that Snort has successfully become a "killer app". The challenge Snort now faces is how to avoid becoming a victim of its own success. Apache is an example of open source code that has successfully bridged the gap from killer app to significant piece of Internet Infrastructure. This success can be attributed to governing and regulating Apaches growth through a consortium. I believe Snort could benefit from the same type of arrangement. Unfortunately, the forces that have brought Snort this level of success are falling out of balance. With Marty at the helm of both a wildly successfully open source project and Sourcefire (a growing, soon to be 800 pound gorilla in the intrusion detection market) he is faced with answering to a board of directors on one hand and the security community on the other. These are opposing forces with dramatically different goals. It is simply not possible for a single person to serve both of these roles and act in the best interest of each.
IMHO, if making Snort a 'better app' is in any way a Bad Thing(tm), then I'm a bit confused. :)
While the number of users of Snort is growing, the percentage of community contributed code is decreasing. The reasons for this are not immediately obvious. Although there is plenty of community interest in contributing code, these interests are aparently in conflict with the goals of Sourcefire. Thus, some contributions have had been subjected to stealth deletions, others have never been incorporated in the codebase or have been re-written by Sourcefire to be more accommodating toward their goals. The most successful of the contributed code has been subjected to consistent negative and inflammatory PR campaigns. Marty carries this out this by proclaiming to the community false and misleading statements such as --- "Many of the contributed plugins, Marty says, 'were bug-filled, crashy, and slowed things down.'"[1] This tactic began to manifest in an unhealthy way a little over a year ago, shortly after Sourcefire was getting started.
One reason things get changed is that the person who develops the codebits, suddenly has no time to update or maintain it. Job, School, whatever--Things like that will cause someone to stop working on a project. Now if I (for example) am to come along and 'maintain' someone else's code--I'm going to change it to 'fit my style'. I may not understand the one letter variables, or odd incantations that someone else uses. As for 'bug-filled, crashy, and slowed things down' part... Yes, I'd say some are/were. I've had many a odd crash or an obvious memory leak--And then I just start commenting out pre-processors to resolve the problem. There have been many times I've seen snort eating CPU on a box. Simply disable one plugin and drop the CPU to less than 30%.
One can only speculate the strategy of Sourcefire in the long run; however, it would be foolish to think the goals of Sourcefire do not include maximizing profits. I have plenty of respect for Marty and I believe he has the best of intentions; however, he is no longer the man with the final say at Sourcefire. The investors of Sourcefire now control the critical strategies and goals of the company. There will undoubtedly and understandably be pressure from Sourcefire investors to gain more control of Snort while creating barriers to entry and stifling the competition.
Long run strategy? That's simple--Make Money. :) One thing that I think you're missing here: _Snort is GPL software._ Sourcefire simply _builds_ on top of that software. Sourcefire does not 'own' Snort. It uses it as a tool/building-block for it's own business model.
There are a vast number of Snort add ons and wrappers (both open source and proprietary) that lead me to believe Snort is on the track toward becoming something of an operating system of intrusion detection that forms a base for numerous applications and business to grow and flourish. I would like to see an environment of healthy competition in this market to benefit the consumer, security community, and provide the opportunity for independent developers and business to find some niche and profit from their work.
More and more things are being written/created for use with Snort every day. It doesn't take a crystal ball to see that the more widespread Snort usage becomes, the more things will be built for it and/or with Snort as a integral component. I see plenty of 'healthy competition' going on with various companies that have a 'Snort Appliance' or that are selling 'Mannaged Snort Services'. I think the only thing that's going to 'hurt' that competition is when folks start to realize 'I could do this myself' instead of buying a pre-made appliance. Training and support--I think thats here to stay.
These are the reasons why I believe now is the time for the community to begin discussing forming a branch of Snort that is governed by a consortium that is not profit driven, but rather exists to support the best interests of the community and support healthy competition among all of the companies that are providing Snort based security solutions.
Errr... This would be a _great_ idea, except for one small fact: Human Nature. As long as we've had "governing bodies", we've had corruption and abuse of power. Thats harsh to say, but IMHO true. Even though it may not be 'profit driven', such a group would be 'politically driven'. :)
This is a sensitive topic, but I believe the time has come to surface it. I'd like to hear your opinion... Is now the right time to begin considering a fork or branch or Snort? What benefits or advantages would this create for end users, business that use Snort, business that provide products or services based on Snort, or the security community as a whole? If a consortium were formed for governing a new fork of Snort who or what businesses, organizations, or individuals should that involve?
IMHO, No. Right now, what I see happening is something that is akin to 'spring cleaning'. I've been working with Snort for a while and I see some things in the code that are no longer needed, or even used. Snort has fallen prey to 'feature bloat' over time. Many of these features could/should[?] be moved into plugins so that Snort remains a fast little piggy. :)
All comments, flames, and opinions are welcome. The sole intention of this message is to initiate discussion.
heh... I'm sure it will do that.... Cheers! ----- Erek Adams Nifty-Type-Guy TheAdamsFamily.Net ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Snort-users mailing list Snort-users () lists sourceforge net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
Current thread:
- RFC: Forking Snort Jed Pickel (Jul 02)
- Re: [Snort-devel] RFC: Forking Snort Ryan Russell (Jul 02)
- Re: [Snort-devel] RFC: Forking Snort james (Jul 02)
- Re: RFC: Forking Snort Erek Adams (Jul 02)
- Re: RFC: Forking Snort Martin Roesch (Jul 02)
- <Possible follow-ups>
- Re: RFC: Forking Snort Andrew R. Baker (Jul 02)
- sorta new at doing this with snort Don (Jul 04)
- Re: sorta new at doing this with snort Imran William Smith (Jul 04)
- sorta new at doing this with snort Don (Jul 04)
- Re: RFC: Forking Snort Jed Pickel (Jul 04)
- Re: RFC: Forking Snort Kyle R. Hofmann (Jul 04)
- Re: [Snort-devel] Re: RFC: Forking Snort Martin Roesch (Jul 04)
- Re: Re: [Snort-devel] Re: RFC: Forking Snort John Sage (Jul 04)
- Re: [Snort-devel] RFC: Forking Snort Ryan Russell (Jul 02)