|< Day Day Up >|
Joining the Open Source Movement
Once you've used the open source security tools in this book and benefited from them, you may feel like you want to get more involved. In most cases, the software is free and you are not obligated to do anything in return for the benefit you receive. However, a lot of time and effort went into building and maintaining the software you are using, all of it by volunteers. The only way that open source continues to work and grow is by the collective effort. This may sound vaguely socialist to some, especially to employees of commercial software concerns, but it is not that different from your local PTA or little league baseball organization. It is the people involved who make open source software great.
In doing so, you will not only help keep open source alive and growing, but also meet friends who have the same interests, make valuable business contacts in your field, and learn a lot in the process about project management, working with others, and of course technical knowledge and experience.
You don't have to be a coding guru to contribute. The key to helping the open source movement prosper is just to participate. There are a number of ways you can get involved, ranging from taking a few hours of your time to this work becoming a second job.
Bug Finder/Beta Tester
Even if you are just a user and have no interest in coding, you can help your favorite open source security tool. Most major projects have bug tracking mailing lists, and some have more complicated systems for reporting issues. If you are working with the program and find something that doesn't work right, report it and see if it can be fixed. In the process of getting your problem fixed, you'll help the developers track down bugs and improve the program. Of course, you will want to make sure that the problem you are having is a software bug and not an installation error on your part, but the people on the lists are usually more than happy to set you straight.
To report bugs properly, make sure that you gather all the environmental variables and try to duplicate the problem to figure out under exactly what conditions the error happens. Things like operating system, version of the program, settings, hardware, and so on are all important. Also make sure you have any error messages, log files, or core dumps for the developers to analyze.
You can also be a beta tester of the latest code. Some projects offer you the ability to run either "stable" or "experimental" code. While most users will use the stable code, you can be a trailblazer and try the experimental or beta versions. Keep in mind that there may be hiccups while using this software, for example, sometimes the new code will break things that worked before. If you are going to run beta code, you will probably want to run it on a test machine before putting it into production.
Other projects may distribute beta code to a limited list of testers. They will want the first users of the code to be experienced users who know they are using beta software. That way, they can rule out the usual newbie mistakes and have users who understand how the software works and can accurately describe their problems. So, you probably shouldn't volunteer to be a beta user until you have some experience with the software. When you are ready, ask the key developers to be put on this list. This way you can help improve the software for future users. The side benefit of this is that you will be the first to get cutting-edge features and you can be instrumental in deciding what new features get added.
Participate in Discussion Groups and Support Other Users
Most open source projects have a mailing list for discussion and technical questions. You should subscribe to this list even if you don't plan on participating right away. You don't have to be an active poster to the list to gain some benefits. It's okay to just "lurk" and read the questions and answers that are posted. I have learned a lot of things about the software that I never would have found out, just by casually following the mailing list discussions. A word of warning, though: Some of these lists are very active and have dozens of messages posted a day. This can be overwhelming for some, especially if you are already overworked like most system administrators. But even reading only an occasional message that interests you can be of value. If you feel you are getting too much e-mail, consider subscribing to a "digest" version of the list, which is a single message you get daily or weekly that contains a compilation of all the messages posted. This way you only get one message and can sort through it when you have the time. Still, make sure you understand how to unsubscribe from a list before subscribing so you can get off the list easily if the volume is too much for you to handle.
Most open source mailing lists use a software package called Major Domo to manage their lists (this is also an open source project!). The standard commands for subscribing and unsubscribing on this kind of system are as follows.
Mailing lists can be operated as moderated or unmoderated forums. In the unmoderated format, anyone can post anything and the messages go up immediately. This is the best kind of list for getting information quickly. However, many unmoderated lists quickly fill up with off-topic conversations, arguments, and flame-wars. That's why most lists are now moderated, which means that a person, the list moderator, must review each post, decide if it's relevant to the list charter, and approves it to be posted. This makes for a much lower message volume that is always relevant, but it may mean your posts for help on a subject are delayed for several days until the moderator gets around to it. And moderators will usually shut down list activity for holidays (moderators deserve holidays too), so getting answers during a holiday may be spotty.
Once you are confident that you can hang with the big dogs, begin making some posts, answer some easy questions, and provide an opinion here or there. This will take the load off of more technical developers by having others answer basic questions, and it will also provide a wider base of knowledge for the whole project. After all, you may have experience with a specific configuration or platform that no one else has—you may be operating in an unusual environment or you might have a different take on a particular question or issue. Chances are that someone out there can use your help. You will feel good about helping others and you'll be amazed at how thankful and gracious the people you help will be. If only your internal users could be so nice and grateful!
Provide Resources to the Project
Here is something you can do even if you don't have programming abilities or much experience with the software. Open source projects generally don't have any revenue to support any expenses incurred in the development and maintenance of the software. While most of the labor is provided by the volunteers, there are still the issues of where to host the Web site for the project, what hardware to put it on, and many others. Again, the participants usually donate most of this. If you have an old machine that could be used as a Web server, let the key people know. You'd be surprised what an old machine can do running Linux and Apache. If your company is amenable to it, see if you could offer to host the project Web site on company bandwidth. Your company might not want to do it if it's a big project, but for small projects just getting off the ground bandwidth utilization will probably be minimal and most of it will be during non-office hours. If you have Web design skills, offer to put up a Web site. If your personal ISP provides free Web site space, offer to use that for the project. A nonprofit endeavor usually falls under your terms of service for personal Web space. Finally, some open source packages even accept good old green backs as a "donation" for using the software. You might be able to convince your company to put up a few bucks as an alternative to paying retail for off-the-shelf software. Anything you can think of will usually come in handy for an open source project. Graphic design skill to design a logo, e-mail accounts to support the mailing lists, legal help in crafting the licenses—all these things represent creative ways to help your favorite open source project.
Patronize Companies That Use or Support Open Source Products
While you don't have to spend your budget dollars on the software, you do spend money on other things. When buying hardware, software, or services, make it a point to give vendors who use or support open source software special consideration. After all, if companies can be commercially viable by using open source software as a key part of their offerings, it only strengthens the cause. Companies such as Sun, IBM, and Dell are heavily promoting open source.
|< Day Day Up >|