MR: So how would you recommend an aspiring open source software developer with time to kill get involved in a project like NeoOffice/J? What's a good entry point?
PL: I would say that the problem with open source, of any sort, or any development, is that developers have to find their own entry point. One thing I've always felt is that when people show up and say, "I'm really interested in helping," my first question is, "Well, great, have you tried compiling it, or have you tried anything?" The most important thing for open source that we're looking for is not people who need their hand held, but for them to prove their competence by slugging it through and trying to build it, and when it doesn't build, don't throw up their hands. What I see a lot with OpenOffice.org development is "It didn't compile." Well, OK, it didn't compile and you haven't fixed it, so you're showing that you're really not interested in helping, or it's outside your skills to be helping.
Assuming you do have the skills, you can get involved by compiling it, and then looking through bug reports--go fix those first. A lot of people I know show up to our site and say, "I'm willing to help, tell me how." So I always tell people, "Great, go compile it, and why don't you go fix one of the bugs we have?" That, unfortunately, eliminates about 98 percent of the people who show up, because that's not sexy.
And one thing I would really emphasize to open source developers is that most software is not sexy. Most of it is very tedious, boring code that will drive you crazy. And if you don't like that, you'll find it very hard to make a living in software engineering.
And to give an example, it took us two years to get NeoOffice/J to the point where it just worked and didn't crash all the time, just because it is such a large application. Even when I was a seasoned engineer at Sun, back in 2000, I still had a lot of trouble really getting my arms around OpenOffice.org. It was just so big. So, in a lot of ways engineers have a really good tool to find their way in terms of how much can they reasonably help without actually getting in too deep. It's really trying to compile it and try to fix a bug, that really makes a good entry point. If you find that even compiling it is just overwhelming, you found out early, without spending too much time, that this probably isn't your project, and maybe you need something smaller. But if you really thrive on that big, nasty code, you'll be drawn to it. That's a good sign that it's up your alley. And that's the nice thing about open source--people can try and decide whether it's their cup of tea or not.
MR: Yeah, so just speaking of the huge size of a project like NeoOffice/J, how many lines of code are we talking about?
PL: Let me put it this way, NeoOffice/J modified only a couple percent of the OpenOffice.org code. I purposefully tried to minimize the amount of code that was changed; but the amount of code that I had to change is probably in the tens of thousands of lines, and that's a small, small percentage. Total source code base if you check out a snapshot from OpenOffice.org is about a half a gigabyte, and it's just huge. As far as size of code, you just can't get much bigger than office suites. They're the biggest and nastiest out there. It's probably an order of magnitude bigger than Firefox.
MR: Wow, how many people contributed to this kind of huge code base over time?
PL: I do know that at one point Sun had at least 50 full-time software engineers working on OpenOffice.org. Plus, they have a separate dozen working on documentation and translations, and probably another dozen working on lease engineering, and another dozen working on quality assurance. They had an organization of well over a hundred people making this happen, and they started this thing about 15 years ago. Now they weren't always at that size. Let's say if you average it out and start at one, we are probably talking an average of 50 people over 10-15 years to get it to where it is today. That's a huge investment.
MR: Yeah, absolutely. Just in the NeoOffice/J portion you've worked on, how many hours would you guesstimate you've spent over these two years, to get it into the nice state that it is?
PL: I haven't kept accurate figures, but I think we are over 3,000 hours now, and then Ed Peterlin spent probably another 400 or 500 on top of that, so we're probably getting close to three man-years now.
MR: Yeah, I was gonna say that that is quite a bit. That averages out to be something along the lines of several hours a day--every single day--doesn't it?
PL: Probably more than that. I hate to admit it, but I actually wake up, and because I work out of my home, I start working on code.
MR: So is it fair to say that if someone asks what do you do for fun, an honest answer would be, "I write code!"
PL: I do like code.
MR: That's excellent, Patrick. Thanks so much for taking time out of your busy life to share details about NeoOffice/J, OpenOffice.org, and open source software development. This really is exciting stuff.
PL: You're very welcome.
Matthew Russell is a computer scientist from middle Tennessee; and serves Digital Reasoning Systems as the Director of Advanced Technology. Hacking and writing are two activities essential to his renaissance man regimen.
Return to the Mac DevCenter