net-snmp provides tools and libraries relating to the Simple Network Management Protocol including: An extensible agent, An SNMP library, tools to request or set information from SNMP agents, tools to generate and handle SNMP traps, etc.
Net-SNMP implements the Internet standard mechanism for network management, including the most recent SNMPv3. It allows system and network managers to monitor and manage hosts and network devices.
Why and how did you get started?
Wes: In 1994 or 1995 I was working for the University of California at Davis and needed to manage a large number of Unix machines (~200) that exhibited particular recurring problems (servers crashing, disk space filling up, services failing to respond, memory running out, and so on). I took the then-unsupported CMU-SNMP package and modified it to work on HP-UX and later Ultrix, SunOS, and others. I originally distributed the work as a patch to the CMU-SNMP package. It was very well-received. I decided it should become its own package. It started as a mailing list and FTP site and now makes use of most of the SourceForge services.
Dave: I wanted to detect printing problems before they got out of hand, and decided that I needed to replace the vendor-supplied SNMP agent. I started tweaking the UCD agent, and feeding the changes back to Wes, and sort of got sucked in from there. That was over nine years ago, and I still haven't got back to the printing problem!
Niels: I received responsibility for a server room at a PPOE in 1995 and started looking around for tools. SNMP looked good on paper, but the available agents were few and lacking, especially from OS vendors. My main servers were Solaris-based, so I started hacking the Solaris support in UCD-SNMP. At that time Dave was hacking the HP-UX parts, and Wes mostly Linux and (Free)BSD.
Robert: I got started with the precursor to Net-SNMP, UCD-SNMP, when the IETF was (unsuccessfully) trying to define SNMP v2 to add security to SNMP. My employer didn't want to wait for the IETF, so I had to add the proposed access control stuff to an existing v1 agent. As I settled into the niche market of doing agent development, I used UCD-SNMP and Net-SNMP again and again, occasionally fixing bugs I found or submitting new features that my clients needed.
Mike: In 1998 I joined Internet Security Systems' X-Force and began investigating different approaches to scanning for SNMP vulnerabilities across large IP address ranges. At the time, a colleague recommended that I investigate UCD-SNMP. I discovered that with careful preparation of the MIB file loading prior to opening any SNMP connection, a parallel set of function calls could be used to invoke the SNMP functionality in a *mostly* thread-safe manner without requiring resource locks. This became the single session API that has been part of Net-SNMP since UCD-SNMP 3.5. After joining Trusted Network Technologies, I did not participate in Net-SNMP development until December 2003, when it became necessary to update the SNMP library and agent builds to work on Win32 platforms. I met Alex Burger and Andy Smith, and we teamed to create the installable Windows packaging of Net-SNMP 5.1.2.
What is the software's intended audience?
Anyone involved with network management -- network administrators, operators, and developers, including those developing their own agents for MIBs that are not included with Net-SNMP (e.g. proprietary devices). Some operating system vendors bundle it with their software, and various hardware manufacturers embed it within their networking devices. Net-SNMP has tried to maintain a fine line between offering new technologies for experimenters, educators, and students, and a robust working product for system and network administrators.
How many people do you believe are using your software?
We don't know. It's likely to be used by multiple people at any given organization. Additionally, it's distributed by Red Hat, Debian, Solaris, Apple, YellowDog, FreeBSD-ports, and available on various package repositories (such as HP-UX packages). I think from the SourceForge site we've hit about 43,000 downloads for a single version.
What are a couple of notable examples of how people are using your software?
I've heard from people that use it in a wide variety of ways, including managing ground-based radar stations, computers in at airport terminals, military devices, and taxi networks.
What gave you an indication that your project was becoming successful?
The volume of email traffic on the mailing lists! We average about 400 a month at least on the users mailing list, and 300 or so on the development list. Another significant indication was when Red Hat Linux adopted ucd-snmp instead of the cmu-snmp-linux package in mid-1998. The most recent major event was when Solaris 10 shipped with Net-SNMP's agent and software instead of their previous Sun-specific SNMP software.
What has been your biggest surprise?
Wes: The friends that I've made through the process. The most outstanding thing about open source development I think is the interaction you get with people from all over the world. It's not only beneficial to the project, but to each individual that contributes as well. It surprised me to have people come up to me at conventions and ask me if I was the one who had started the project and tell me they used it loved it and used it extensively. I never expected to be discovered in a crowd because of my name tag merely because I started a project to help people make use of an obscure management protocol.
Dave: My biggest single surprise was being asked to write an article about the project in the Simple Times (Vol 10, #1). More generally, I'm continually surprised at how many independent projects rely on our code, and how highly we figure in the SourceForge rankings. We've consistently been in the top 1% (almost three-quarters of our time here overall, and solidly for the last year plus) and have only dropped out of the top 10% once in over four years. Not bad for what is a somewhat specialised package!
What has been your biggest challenge?
Wes: The high portability of the package poses the biggest challenge. In order to keep every part of the software supported, we need developers who have knowledge about the internals of many different system types. As people come and go from a project, it's hard to keep a good spread of those who can answer questions about hardware that the core developers don't have available. The SourceForge compile farm has certainly helped this endeavor, but Net-SNMP's daemons frequently need root-level access for device access, and the variety of hardware Net-SNMP has code for is much larger than exists in any one place. A diverse developer set is a necessity for the project to continue to support as many platforms as possible.
Dave: Responding to the growth in usage of the software -- in particular the number of queries on the mailing lists. Providing a useful level of support can be a significant workload.
Niels: We are constantly trying to keep up with new OS versions that keep changing the interfaces to the data we need.
Robert: Trying to balance work, a real life, and contributing to an open source project.
Why do you think your project has been so well-received?
Wes: We try really hard to figure out what is missing from the project based on current mail to the lists, and to see if we can support that in future releases. My early policy on what to work on next was to work on something that would help reduce the most frequently asked question on the list. The result was, unfortunately, not fewer questions but rather more difficult questions, but I'm still an avid proponent of that technique.
Dave: Our software is surprisingly portable (considering that it "just growed") and runs on a wide variety of systems. It's also fairly broad (providing both an SNMP development toolkit and a range of client applications as well as the extensible SNMP agent), and the agent itself provides a useful amount of information out of the box.
Niels: It both implements a large set of MIBs in itself, and at the same time is extensible both by scripting and by adding code.
Robert: It's free, it works, and it is distributed under a BSD license. The BSD licence is a big deal, since companies that are leery of the GPL use our code in their devices.
Mike: The core developers are responsive and helpful to newcomers and experienced users. I think their quality rivals many companies who charge for support.
Where do you see your project going?
Wes: SNMP is a useful protocol, but it's hard to use sometimes, not because of the complexity of the software or the protocol, but because of the complexity of the data it's trying to manage. I'd like to see Net-SNMP do a better job trying to reduce that complexity wherever possibly by adding more powerful aggregation tools.
Dave: The main thrust recently has been in improving the APIs, particularly with the aim of making it easier to develop new MIBs. This is likely to continue. I also expect to see an increase in the range of systems that it runs on, and improvements in the support for existing architectures (particularly on Windows systems).
What's on your project wish list?
Wes: The current trend in network management is distributed management. When networks scale to really large sizes, central management becomes a burden. It would be nice to see Net-SNMP branch into areas to fix this problem.
Dave: Re-structuring the library code. The v5 release saw significant improvements to the organisation of the agent, making it much more modular and flexible. The library code hasn't really changed that much from the original CMU suite, and is long overdue a comprehensive review. I'd also like to continue revising and updating the UCD-specific MIBs, to address some of the design problems that have come to light over the last 10 years. This could also involve closer links with the Host Resources MIB implementation, perhaps using some form of hardware abstraction layer.
Robert: Multi-threading. I don't think we'll get to it any time soon, though.
What are you most proud of?
Wes: The high quality of developers that the project has attracted.
Dave: Probably the AgentX implementation. Several people have worked on this since I first wrote the code, and it's now much more solid and reliable. But the basic design has proved sound, meaning that the MIB developer doesn't need to worry about how the MIB will be included in the agent.
If you could change something about the project, what would it be?
Wes: I'd like to rewrite the entire configure script. I think we must hold a record for the largest configure script ever written, and it shows. Fortunately, changing it is a realistic goal, but a hard one. The functionality is all still needed, but the tangled web that encloses it could be drastically simplified.
Dave: The code structure -- especially that of the library. Both the file organisation and the data structures are far from ideal. Unfortunately, we've always felt constrained by the need to keep backwards compatibility with existing code, which limits how much we can change.
Robert: I'd like to do a complete re-write. This code has been around for a long time, and had lots of different people tacking on bits and pieces here and there. That makes for a bit of a mess.
Mike: I would like more online collaboration through a wiki mechanism. We use email extensively, and it is difficult to grow ideas that way.
How do you coordinate the project?
Coordinate the project? What a good idea - we should try that sometime!
But seriously, much of the coding tends to be done independently, by people working on a specific area of functionality. We rely on email to keep each other informed about what we're doing. The aim is to discourage developers from going quiet for an extended period, and then suddenly coming out with a whole new subsystem. Commit little and often is the rule. We have a mandate that all development and design decisions be vetted on our development mailing list.
Do you work on the project full-time, or do you have another job?
If you work on the project part-time, how much time would you say you spend, per week, on it?
Wes: It varies widely, from 10 to 50 hours. A lot of the time, I'm not always working on things that directly affect Net-SNMP immediately but do affect its future. For example, I'm currently sitting in a meeting at the IETF about the future of SNMP security.
Dave: Until recently, probably an hour or two a day answering queries on the mailing lists, plus whatever time I can find for coding or documentation. That could easily come to something like 30 hours a week.
Niels: All that I have now to give the projects is 1 to 2 hours a week.
Robert: 10 to 20 hours.
Mike: As many as it takes to propose, foster agreement, implement, test, and check-in. That usually runs less than 20 hours a week when I'm fired up.
What is your development environment like?
Wes: I develop almost entirely on Linux on a x86 laptop these days with the gcc compiler. I do all of my debugging directly in gdb (sometimes within XEmacs) and/or the Perl debugger.
Dave: Predominately Linux - some HP-UX, and occasional dabbling in Windows. I'm a Luddite at heart, so tend to use the old-fashioned approach (vi/gcc/gdb cycle) rather than a full IDE. A lot of both documentation and coding gets done on my laptop in text mode during the train journey to and from work.
Niels: x86, SPARC and VMware; Solaris 8, Solaris 9, Linux, FreeBSD 4 and 5, NetBSD 1.6 and 2; gcc; gdb; dmalloc.
Robert: YellowDog Linux on Apple PowerBooks, for primary development. Mac OS X (via MacOnLinux) for testing. Fedora Core on a generic AMD machine, as primary server and for testing. I use Xemacs to code and compile, and DDD for debugging.
How can others contribute?
Wes: The best way is to participate on the mailing lists. As we frequently say, "patches welcome." That being said, in the same way that we encourage the primary developers to discuss new features on the mailing list first, we'd hope that other developers of new patches would follow suit. Patches can be submitted via the "Patches" tracker system, or posted to one of the mailing lists.
Dave: One area that is sadly lacking is good documentation -- how to configure and run the agent; how to use the existing tools; how to develop new ones; how to design and implement new MIBs; etc.
Another useful contribution would be assistance with "unusual" operating systems that the core developers don't have access to. It would be useful to have feedback as to whether things work properly on other architectures, particularly during the pre-release cycle. Suggested fixes would be ideal, but even just reports of a problem can prove very helpful.
There's a wishlist of various projects on the Net-SNMP Web pages at http://www.net-snmp.org/dev/projects.html
Niels: Our main problem is keeping up with evolving operating systems. Our prime development systems are various Linux systems. Some OSes have ports and packaging of Net-SNMP, and it really would be a help if these porters communicated back to us with their patches.
Robert: The two areas that could use the most help are support on the mailing lists and documentation.
Mike: Those who have time to run a software metrics analysis (how frequently function b is used, and its call distribution across the base) are welcome to do so. Testing is one area that the project could use work in. The "make test" scripting helps develop confidence, and other "unit test" types of verification would go a long way in identifying regression points.
Project Name: Net-SNMP
Name: Wes Hardaker
Occupation or experience: 17 years
Education: MS in Electrical Engineering, UCDavis.
Location: Davis, CA USA
Name: Dave Shield
Occupation or experience: Senior Experimental Officer - 15 years at University of Liverpool
Education: Masters in Computer Science (Manchester)
Location: Liverpool, UK
Name: Niels Baggesen
Occupation or experience: Developer and network manager, State and University Library
Education: No formal exams, but programming since 1970
Location: Aarhus, Denmark
Name: Robert Story
Occupation or experience: Senior Software Developer. 22+ years of programming experience.
Education: BS Computer Engineering
Location: Atlanta, Georgia
Name: Mike Slifcak
Occupation or experience: Software engineering designer
Education: Two years college electrical engineering major
Location: Woodstock, Georgia
Quote about SourceForge.net?
SourceForge is just a gift for projects like ours, taking care of server operation, storage, backups, bandwidth, and other boring tasks, so we can concentrate on developing. The outsourcing of the project infrastructure services to SourceForge frees up amazing amounts of time from project developers so they can do what they do best: write code.
Why did you place the project on SourceForge.net?
To make use of its extensive services.
How has SourceForge.net helped you?
The outsourcing of the system support meant we no longer had to suffer that burden. We could then concentrate on coding and other elements of project management. It's allowed project administration tasks to be shared more widely among the core development team. It maintains the infrastructure for us, and keeps the mailing lists, forums, CVS, FTP, and HTTP servers running.
The number one benefit of using SourceForge.net is:
The infrastructure and the range of facilities it offers and maintains, freeing us to concentrate on the stuff we're actually interested in.