Re: RFC: Forking Snort

[Jed Pickel <jed () pickel net>]

Based on the discussion I would like to share with the community my
conclusions of the "Forking Snort" thread and then clear up some
mis-understanding of my motivations. My conclusions are based both on
messages that were posted publicly and from people that contacted me
directly.

First off: I sent the last mail based on what I've witnessed as a
growing dis-satisfaction and concern over the management of Snort over
the past year. My leaving the Snort project 6 months ago was part of
that and I recently have received an increase in private communication
about the topic. Being in a decent position to stick my neck out I
crafted the last message in an attempt to get a gauge on the community.

I will state for the record at this point that I believe a fork in Snort
is not the best route for the community at this time; however, I believe
some changes in management philosophy and process for Snort are
necessary to prevent a fork. The changes I am proposing are in the best
interest of users, developers, third party businesses, Sourcefire, and
the projects current leadership in my opinion.

Choose to consider the following comments as you wish. These comments
include both my own opinions and some from those that contacted me
privately, but I stand behind them all. These comments are intended to
be productive for the long run so please consider them with an open
mind.

Mixing the "benevolent dictator" model with business
------------------------------------------------------------------
I believe Snort would benefit from a change in management philosophy and
that the current leadership is capable of implementing and following
through on these changes.

To explain the reasons lets consider what would happen if Linus Torvalds
were the CTO of RedHat.

* Would Linus accept contributions to the Linux kernel from the Debian
  or Suse folks?

* Would existing third party code contributions be "scrubbed" if it
  meant solidifying RedHats market share and increasing sales?

* (Or -- following on a previous post) What if a contribution would
  be a huge leap in Linux kernel technology but it would mean rewriting 
  the proprietary pieces of RedHat Linux all while dealing with customers
  demanding this feature. Would that contribution to the "open-source"
  Linux kernel be delayed or ignored?

* What would happen to the Linux kernel if the RedHat investors sold
  the company to Microsoft for some ridiculous sum of money and Linus
  had signed a non-compete? The "benevolent dictator" would be out of
  commission and the Linux community as a whole would suffer,
  particularly if the intention of Microsoft was to disrupt their main
  competitor. Would the fallout halt the progress of Linux while a new
  management structure forms out of the chaos? 

* Or would the Linux kernel either pro-actively fork or be forced into 
  a different style of management because of community pressure to
  avoid the above problems?

Sourcefire can continue as is for a while but conflicts of interest
are going to come up regardless of the promises from Marty. Walking
the fine line of preventing a fork and maximizing profits can be
avoided all together by pro-actively changing the management style and
philosophy of open-source Snort.

I'm a big fan of the "benevolent dictator" model and I think it works
beautifully when profit is not one of the primary motivators of the
dictator. When profit motivations are thrown into the mix measures have
to be put in place to retain the public confidence that these conflicts
of interest can not manifest. No doubt there are times when business and
open source goals run in parallel. The above hypothetical analogy of
Linus as the CTO of RedHat are a few examples where they do not.

One of certainly many possible ways to address this issue could be for
Sourcefire to create a non-profit corporation to manage open-source
snort. A possible way to structure such an organization is how the
Apache folks have. Take a look at this url
(http://www.apache.org/foundation/roles.html) for an example. The ideal
would be to ensure that a diverse group is represented on the Board Of
Directors for this non-profit corp including users, developers, and
businesses that provide Snort based solutions.

Take significant steps now to prohibit conflict of interest issues and I
believe that Snort will unify and get stronger than any of us ever
imagined. I believe this would ensure the goals for Snort mentioned in
Marty's message would not only be met, but significantly exceeded.

Well defined processes for code contributions and "scrubbing" code
------------------------------------------------------------------
One way to increase the number and quality of contributions is to have a
well defined process for contributing code. Why do I mention this? 
Because shortly after I sent the last message half of the private
responses I received came from people or organizations that tried to
contribute code or bugfixes. They never received any response whatsoever
from the Snort leadership.

Obviously, certain requirements have to be met for code contributions. 
When a contribution does not meet those requirements tell the
contributer the decision and if possible point out the deficiencies in
the contribution. Contributers improve the quality flexibility of Snort. 
Snort would not be what it is today without its contributers.

As for scrubbing --- scrub away, but tell the maintainer of that code
why their code is being scrubbed or what they can do to address the
problems to prevent it from being scrubbed. Many contributers have often
made a large investment in Snorts success and they deserve at least that
much.

As a disclaimer --- My past code contributions are not my motivation for
bringing up these issues. I personally don't care what is done with any
code I've contributed in the past. Scrub it, delete it, throw darts at
it. I won't loose any sleep over it. I am aware of a number of
organizations that use some of that code in their production snort
installations and couple companies and organizations that have built
products and services around some of that code. They might loose sleep!

Now for a few responses....
------------------------------------------------------------------
Alfred Huger wrote...
> You don't happen to have a business plan in hand that requires Snort
> by chance do you? Or better yet are you working somewhere that does?

No! My motivations are solely to protect open-source snort, see its
continued growth and improvement, and continued increase in market
share. To fully disclose, my only business in the info-sec industry is
occasional independent consulting (Incident Response and Code
Development). My past, present, or future role in the Snort community is
not relevant to that effort. The majority of my current business
ventures are in other industries.

Martin Roesh wrote (these 2 comments are from different messages)...
> Having code accepted for inclusion in the base Snort distro is a
> privilege, not a right, you aren't entitled to seeing your code go
> into Snort just because you ship it over.
..
> I get a lot of patches and contributions otherwise and only review
> what immediately piques my interest or what I can get to.

You have every right to make that decision. I believe that Snort would
find more success if contributions are encouraged and if those that have
made the investment to contribute have a well defined process, including
guidelines and requirements. Contributors also deserve a response and a
reason if their code is not accepted. Or not... But the consequence is
that pressure will continue to build for a fork.

Andrew Baker wrote...
> It was assumed the developers of the existing output plugins would
> port over their existing code to Barnyard.  However, this has not ever
> come to pass and thus to bridge the gap

Here are two examples of how this statement is false.

* Database plugin: After discussing porting my Snort contributed db 
  plugin to Barnyard on the snort-admin list and completing 90% of the 
  port you released an incomplete plugin that only included MySql 
  support. Had I known that your intentions were to replace the 
  database plugin, I would have never bothered investing my time porting.

* A Barnyard port of the XML plugin was submitted 3 months ago yet I 
  still have not seen it in the distribution. 

So exactly what is required here to "bridge the gap"? I don't understand
your underlying motivations or the logic behind criticizing for not
contributing code while at the same time not acknowledging or accepting
contributions. Another mystery about Barnyard is the reason for the
license changed from GPL to QPL.

Ryan Russel wrote...
> 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.

Very true. It is a nice insurance policy. Although, I would not like to
see a fragmented community. Hopefully Sourcefire will do the right thing
to prevent that from happening.

Jed Haile -- the other Jed :) wrote his one...
> Another thing I should point out, as one of the developers of hogwash, is
> that if you want to do your own thing with Snort, have at it. Marty and the
> rest of the Snort team have been fully supportive of the hogwash team's
> efforts. Hogwash is in many aspects a fork of Snort, it is also a project
> that I hope to one day see merged with Snort. Marty has expressed that he
> would like to see that also.

Obviously anyone can fork at any time they want. There is also the
snort-adapter fork. The fewer forks the better IMHO. The reason this has
not happened more often is that this requires significant investment of
both time and money, not because people have not wanted to. I'd like to
see people unify around one version of Snort and I believe some changes
in management style would facilitate this.

My Concluding Thoughts
------------------------------------------------------------------

I want to thank everyone for their opinions. This has helped clarify
many issues to me and hopefully the users and developers on these lists. 
This discussion has led me to believe that a fork is not the best route
at this time. Nevertheless, I believe we need to encourage the current
leadership to put measures in place to avoid conflicts of interest and
have a well defined and open process for code contributions.

Regards,

* Jed Pickel


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
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