MJ Ray wrote:

However, 14 other VMware products are not, AFAICT. Also, one may study qemu and adapt it to your needs (such as FreeBSD support), or have it adapted, in a free market way, and its licensing does not limit your server memory size, or impose other bizarre arbitrary restrictions.

I recently decided to do precisely this (not with Qemu, but with a GPL licenced home accounts package), and I quickly realised just how much stuff I don't know (and need to know) just to get started. In this case the package is cross-platform and uses wxWidgets, but the instructions I had to get set up were Windows based (using the free-as-in-beer MS Visual C++ Express as the compiler), and I decided to follow that route (for a whole range of reasons which aren't relevant here). The problems I had getting started were probably fairly generic, though. I realised that whilst I've occasionally used CVS in the past I didn't really know what I was doing with SVN, so that was hurdle number one. Installing all the relevant libraries and getting all of those to compile was a major hurdle (and I'd like to think it was because of the platform I was on but I don't really think that's true). Getting the actual application to compile when I got that far was easy, but then (it surprised me to realise) I didn't know how to generate diffs (again the platform didn't help, but I wouldn't actually have been any more able under Linux). And I'm fairly technically literate, have been coding in various languages since I was about 11 (ZX81 basic!!), and I really should know better. So the point I'm getting at is that the barrier to entry to FOSS development seems very high and I couldn't find any simple getting started guides (maybe I didn't look far enough). SVN is one of those packages which is really well documented, but I didn't need that - I just wanted to get the latest code onto my PC, know how to get updates, and how to submit patches. wxWidgets is similarly well documented but I simply couldn't compile it, and to be honest probably shouldn't have needed to: binary library files would have been enough for what I wanted to do. There are so many applications out there which probably just need one or two line fixes here and there to improve them, but whilst the code change might take a few minutes (in my case that is how long it took to fix the bug that I was hunting for) it took about a fortnight of playing around to get to a position where I could start. (And doesn't C++ take a long time to compile!) // Not sure if this is just a rant, or whether I'm asking for help somewhere. If there is a good "getting started in FOSS development" book I'd like to know about it. Something with a bright yellow colour aimed at "Dummies" might be useful! But these days teaching kids to use computers in school means teaching them to use office (and usually Office[tm]) applications, not teaching them how to program. FOSS is missing a trick if the barrier to entry can't be lowered so that the ideal of fixing those bugs that annoy you then submitting them back to the community can actually be achieved by a moderately competent person in the real world. -- Mark Rogers More Solutions Ltd :: 0845 45 89 555

cl@isbd.net wrote:

I think one of the things that can be difficult is the major difference in "shape/philosophy" between development in a Unix(ish) environment and a Windows(ish) one.

Yes, this is true, but not so much with a cross-platform OSS development where the philosophies have more in common. As I mentioned I did have the option of compiling under Linux; but when I looked at it I had exactly the same questions as under Windows (I still didn't know my way around SVN, wxWidgets, etc). I stuck with Windows mainly because I needed to test the final application under Windows, for other less enlightened folk in the family.

In some ways I think a bit of a significant learning curve may not be a bad idea. There needs to be some sort of level of competance before someone starts submitting code changes. I'm desperately trying not to sound elitist here! :-) I suppose it's akin to the problem of protecting Wikis from antisocial/incompetant people.

There's some truth in this, but what I'd want to do is lower the barrier, not necessarily remove it. I do a lot of PHP work and I'm only too aware of what can happen when everybody gets to program, but I think that a continuum from "user" to "programmer" is better than a big (and widening) gap between them. After all we're not talking about letting anybody make changes to the main codebase (which would be the Wiki parallel). Sure they can submit changes, but they'd need to be audited by the project's "owner". In the case of the accounts package I'm playing with, it (by the author's admission) isn't all great code, and many of the things I'm submitting back are just tidying and fixing the code. It can work both ways - its easy to assume that the code nobody can touch is really good code because of it, but I doubt that's true in practise (FOSS wouldn't work if it were!). -- Mark Rogers More Solutions Ltd :: 0845 45 89 555

Mark Rogers <mark@quarella.co.uk> wrote:

I recently decided to do precisely this (not with Qemu, but with a GPL licenced home accounts package), and I quickly realised just how much stuff I don't know (and need to know) just to get started. [...]

Well, I did also mention "have it adapted"... but is that just a hope stated by people who understand some software package(s) that isn't properly documented or easily understood? ;-) Anyway, I still have the same problem sometimes, when meeting new ways of working or new components. Often they aren't documented and sometimes my need to get the work done means that I don't map my path in as well as I should. I'm getting better, using git (the kernel version control system, which seems to be able to work independently even if upstream uses CVS or SVN or whatever) and trying to keep my own Changelog, README and NEWS. I'm probably still not publishing them as often as I should, though, and my contributions of in-code documentation (POD, autogsdoc, mole and whatever the php one is called) are still not as frequent as they ought to be. Version control command lines suck. If possible, either put the common commands into a Makefile (I've usually got "make download" to update to the latest version and "make check" to run git status, cvs status or whatever) or use a plugin for your editor (Emacs VC-mode seems pretty good to me). Do you need to use version control at first? Often I start development of my extensions on the last stable release, rather than the developers' version control. I know lots of people tell you not to do that, but I find it works for me, most of the time: I don't have to worry so much about other bugs in the core between releases, but sometimes it does mean you hit a known bug and have to port your changes forwards sooner than expected. Also, if a package has got neither a working stable release or a good developer's introducts, you should be very cautious about getting involved. When contributing a feature originally developed on a stable release, I unpack the latest development source, the stable source I started from and my modified source and use a 3-way merge tool (Emacs emerge with ancestor most often IIRC) to port my changes forward into the latest development source. Then a version control diff gives me a patch to submit.

Not sure if this is just a rant, or whether I'm asking for help somewhere. If there is a good "getting started in FOSS development" book I'd like to know about it. [...]

They're no dummies books, not free-software-specific but http://www.robson.org/gary/writing/becomeahacker.html and http://www.catb.org/~esr/faqs/hacker-howto.html may help. Beyond that, I guess questions here, IRC or the various message systems are as good as anywhere. Beware bad advice, though. I ranted about this recently in http://mjr.towers.org.uk/blog/2006/software#bewarewebadvice and if I had a fiver for every time I saw a web app install guide that instructs users to chmod 777 (a+rwx) a directory (a bad idea 9 times out of 10), I'd be buying all the beer at ALUGs. Learning programming well is a good idea. I think it helps if you have at least understood a bit more than 'Hello world' with at least one from each of these lists: 1. Mostly imperative: C, Perl, PHP, BASIC, ... 2. Mostly object-orientated: objC, C++, Smalltalk, Ruby, ... 3. Mostly functional: Scheme, CLisp, Elisp, Haskell, ... 4. Mostly unusual: Forth, PostScript, SQL, Tcl, ... (Note I wrote *mostly* - these days, it's almost all languages can do all styles, which is why knowing at least one of each is helpful.) http://www.levenez.com/lang/ for links. I think the biggest problem I have as I get older is remembering that nearly all software problems are either: a. easy; or b. easy after redesigning the software; but it's not always easy to tell which is which if the documentation isn't understandable to you, and redesigning is often more work than it's worth, especially if you face flamey opposition from the present designers! Hope that helps, -- MJ Ray - see http://mjr.towers.org.uk/email.html North End, Lynn, Norfolk, England Work: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request

Hi Mark On Tuesday 12 September 2006 18:57, Mark Rogers wrote:

...

Version control command lines suck. Do you need to use version control at first?  

In this case that's the only mechanism by which the source is available. I'm sure the author would have emailed me a .zip/.tar.gz but I'd rather I learnt SVN.

"svn ci" and "svn up" are pretty much all you need to get started - Nothing ugly or complex there that needs stuffing in to a makefile... I found both http://cvsbook.red-bean.com/ and http://svnbook.red-bean.com/ well worth downloading and reading - Probably less than fifty pages from both covers most of what the average person needs to know about either subject. And even for simple little "hello world" projects, running a revision control system is worth doing - If nothing else, it gives you a bit of experience of using the stuff ;) When you get deeper in to OSS development, autoconf & automake are also valuable tools to get to grips with. Regards, Paul.