Re: [Snort-devel] RFC: Forking Snort

[Ryan Russell <ryan () securityfocus com>]

On Tue, 2 Jul 2002, Jed Pickel wrote:
> 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.

Is there any evidence that Apache's success is a result of there being a
consortium?  I mean that seriously.. I don't know all that much about the
project and how it is run.

> I believe Snort could
> benefit from the same type of arrangement.

Well, that implies that somethign would be improved, or a problem would be
solved, by a group making decisions for a Snort branch, or perhaps that
that's just a better way to run such a project. As far as managing an
open-source project like this, I'm a bit more familiar with how the Linux
kernel is run, which is to say that there's generally a single person or
small group of people who make decisions, set directions, and decide which
code is or is not accepted. Linus says he is able to make improvements
faster this way. And of course, there are distro vendors who are free to
include whatever bits and tweaks that they wish.

> 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.

That the goals are opposed is an assumption on your part, unless you have
specific proof that the SourceFire board is specifically against the
security community in some way. It is entirely possible that the board
will/has decided that serving the security community also serves
themselves. I acknowledge the potential for a conflict of interest, but
essentially, I'd rather wait and see if there is going to be a problem.

> 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.

My personal observation is that community contribution has decreased, but
only as a percentage of contributed work. My observation is that this is
due to a huge increase of code production on the part of the core Snort
developers, who now work for SourceFire, and are now paid to write Snort
code. They don't have to have other day jobs and write Snort on a
volunteer basis. The other reason is that Snort is preparing for a major
revision release, and developers are finding that their need is already
being addressed, or are waiting to hack on a stable version of 1.9.

> 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.

Their stated goal is "stablity". I haven't looked at any of the code
myself to see if it's fair to believe that code has been removed,
re-written, or rejected because it hurts stability. I can say that I have
observed an increase in stability in Snort over the 1.8 series, as a user,
and as someone who observes the various Snort forums.

If you have evidence that SourceFire is holding back cool Snort Stuff for
other reasons, to meet some other goal, I'd like to hear it.

> 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.

I hear a lot of the same from Linus. While neither Marty nor Linus may be
being terribly diplomatic about it, they may also both be being entirely
truthful and correct. You attribute this to the forming of SourceFire, and
presumably a financial interest. I happened to be chatting with Marty
right when SourceFire was being formed, and his intention was to clean
house once he started working on Snort full-time. So I think using the
word "unhealthy" isn't quite accurate.

> One can only speculate the strategy of Sourcefire in the long run;

Which is what you are doing.

> 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.

Or maybe they're of the opinion that having broad Snort adoption, which
drives rule-writing and other people writing code, only helps their
business. One can only speculate, or wait and see.

> 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.

That is one area where Marty has specifically said that he doesn't want
Snort to become something more than it is. As someone who writes rules for
Snort, I'm always asking Marty and crew for some new feature. Marty's
primary decision tool for any new request I give him is how will it impact
performance?

> 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.

And there's nothing to stop them. Even if your worst case comes true, why
would it stop the independents? The worst monopoly in our industry,
Microsoft, still leaves tons of room for others to make money. And you're
a whole lot better of with Snort, because it's open source and you CAN
fork if SourceFire goes nuts and releases the next version only to paying
customers.

> 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.

Right now, the only groups I see that would be served by a fork are other
companies with a commercial interest in Snort. Now, that doesn't
automatically mean that it's still not a valid interest. Certainly, I can
see where companies that now compete directly with SourceFire would have a
concern that they have Marty. Again, I look to the Linux model. If company
XYZ wants to make their own Snort distro, good for them. Their best bet
for success is to differentiate their product on features. If Marty
doesn't want their code in the main Snort codebase, all the better for
XYZ. If XYZ is right that they've got somethign cool, then people will use
their distro/appliance/service whatever.

> 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?

If it's not obvious, my opinion is "no".

> 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?

Right now, I think that Snort still has lots of growing and refining to
do, and from what I hear, that's most easily done with a small group or an
indivdual.

Add to that that I have a problem with trying to take away someone's baby
when they are still advancing it and have not demonstrated and conflict of
interest. My experience has been that when and if something happens that
the community isn't happy with, then a fork will happen. I see no reason
to force the issue because a *potential* conflict of interest *might*
cause problems.

Having said all that, since it's GPL code, you can fork anytime you feel
like it. Why not get together all the independent coders who feel that
their code isn't being used as it should, and go from there? If that isn't
what they want, then this effort may simply be someone trying to bully
Marty into doing what some other group wants, and there's no reason for
it.

                                                Ryan



-------------------------------------------------------
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