| Non-programmers |
If you don't program at all, there are a number of things that you can do. The main one is to just use UML. Report any bugs, problems, or rough spots that you encounter. If you find workarounds, tell us about them, too. There are a large number of different kinds of environments out there, and there may be assumptions accidentally built in to UML that cause it not to work, or not to work well, in some of them. The more people we have using UML, and the wider the variety of situations it's used in, the more robust it will become.You can check the documentation - you probably will do so in the course of learning what you can use UML for. The main thing that you can do is report any problems you find.
If you want to help in a more systematic way, you can
Documentation fixes will be accepted in any usable form, including a general description of something that needs doing, suggested text as just text, or fix to the XML source for the documentation.
- proofread it - I try to be grammatical and spell things correctly, but sometimes mistakes slip through.
- fact-check it - in particular, make sure that the step-by-step procedures actually work. They occasionaly get out-of-date, describing methods of doing things that no longer work because new ways have been introduced and the old ways removed. They may not work in all environments. They are mostly written up after I've got them working on my laptop. Your machines may differ, and they may differ enough that my procedures don't work for you. Also, I may have found a overly-complicated way of doing something. If you know a simpler way, you should let us know about it.
- style-check it - it may be that a way of doing something is correct, but poorly worded or confusing. If you get lost trying to do something, you should complain about it. If you persevere and figure out how to make it work, it would be very useful for you to go back over the documentation and see where you got lost. Then, figure out what it could have said that would have prevented you getting lost, and send that in.
If you want to get more involved in the documentation, it is described here.
| User-space programmers |
If you want to contribute code to UML, but you aren't a kernel hacker, there are a number of areas that need work. There are a number of tools that come with UML that aren't strictly part of it, but which make using it easier in some way (such as the uml_net networking helper) or which provide access to UML functionality (such as the mconsole client). There are a variety of enhancements that can be made to these.Various applications of UML are going to require tools which don't currently exist. For example, for UML to be most useful for virtual hosting, there need to be tools which can configure and run a virtual machine for a new customer. People who are doing networking of clustering experimentation with UML need something similar, except that it needs to be able to construct a specific network of UML virtual machines.
The UML packaging is somewhat ad-hoc at the moment. I've learned enough about both RPM and Debian packaging to be able to put together defensible UML packages in both formats. However, I'm sure that they would not be considered 100% kosher by either camp. So, there is a need for packaging experts to have a look at the UML packaging procedures, find the mistakes, and fix them.
Contributing code to UML itself is not completely out of the question if you're not a kernel hacker. Since UML is a port of the Linux kernel to Linux, the lowest levels of the code, which in other ports, are hard-core hardware-specific code, are generally fairly straightforward userspace code. That code does stuff like read files, talk to pseudo-terminals, communicate over the net, etc. It's perfectly possibly for people who don't know about kernel programming to contribute useful stuff here.
| Kernel hackers |
If you're a kernel hacker, you can find and fix bugs in UML. I've listed the bugs (and some features) that I want to fix before UML V1.0 here.There are also a number of longer-term projects described here. These are the post-V1 things I want to do, but I certainly have no objection to people starting work on them now. They include things like adding SMP support, implementing clusters of various types (first DSM-based clusters, moving to more standard RPC-based clusters), making Linux a better host for UML, ports of UML to more architectures and to other operating systems, and a variety of other things.
| Other contributions |
There are some things that you can do to help out UML, no matter who you are:
- New applications - I have a number of applications of UML listed here. I am but one person and my imagination is limited. If you find UML useful for something and it's not listed there, let me know.
- Propaganda ... err, spreading the word - If you find UML useful for something, chances are you know other people who are doing the same thing who don't know about UML. Tell them about it. Recommend most strongly that they start using it. If you know of web sites or publications that would be interested in UML, suggest that they write about it.
- Donations - Other sorts of things will be cheerfully accepted
- Hardware - A good rule is that anything that gives me faster kernel builds is good. SMP kit is also good, since UML has displayed races on SMP machines that aren't seen on UP machines. Non-x86 hardware is good, particularly if it comes with an interesting vendor OS (i.e. VMS or OS/400). This will help out the UML porting situation.
- Money - It can be exchanged for the aforementioned toys, so it's good too.
- Anything else - Get in touch and we can discuss it.