KOffice Team: A Handful of Coders, a Lot of Code

nickbrown writes: "In this interview with the KOffice development team it is revealed that only about 4-6 people are working on the suite of applications. It would appear they lack the resources to keep up with the likes of openoffice. Worth a read as it highlights the troubles they are having trying to produce a truly productive office suite for KDE."

Comments

How about collaboration?

[jlrowe]

The project is so big, to compete with MSO, that perhaps all the different groups (OpenOffice, KDEOffice, Gnome office, Gnumeric, Abiword, etc) should all collaborate somehow and make a killer product. Then maybe we'd have a MSO killer.

All the elements are there, and it's all open source anyway, so how about 'together we stand' and not 'divided we fall'?

Re:How about collaboration?

[yintercept]

collaboration also has its cost. To make collaboration work you have to devote more time to the logistics of the collaboration than the current team is spending on coding. I love the idea of a team putting out an office suite with 350,000 or less lines of code. The effort has a good chance of capture the fast, efficient niche of the market. PS: I must admit I am envious of the people on the project.

4 to 6 employees

[yintercept]

While I wait for the poor slashdotted server to retreive the article, I should mention that the right 4 to 6 people can outperform the wrong 400 person programming department.

Small teams often can focus on the issues at hand and make a more tightly tuned product than the big teams, and if they fail...not as much is lost. This is especially true when you have a good well established foundation onwhich to build.

Scratch an itch?

[Anonymous Coward]

Where's the "scratch an itch" factor in coding an office suite? People that are smart enough to contribute to these projects tend to prefer logical markup such as LaTeX. So you'd expect very few OSS programmers choosing to work on this as their hobby.

Unrealistic Goals

[lkaos]

The Free Software community is more than capable of delivering an office suite. 4-6 individuals in not a bad team, but they should be focusing on a specific component instead of trying to do it all at once.

Abiword is an excellent word processor and Gnumeric is a great spreadsheet program. Gnome's figured it out. No one wants to work on a large, bloated project for free. Break it up into littl projects and you'll get a couple 4-6 individual teams.

Of course, the article is /.'d already so I am only guessing...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:a better article would be an investigation of .

[Fnkmaster]

Software developers rarely agree on things. I've seen fights (usually relatively calm and technical ones, but sometimes escalating to heated yelling and nearly to blows) in engineering team meetings. The only thing that forces people to work together at a company and come to agreement on some idea (often a shitty one, but decided for them nonetheless) is MONEY. Quite simply, your employer is paying you. Sometimes you just have to give up and accept that the motivations of the source of the money need to be accepted if you want them to keep giving you all this nice cash, rather than your own concepts of what is nice, aesthetic or well-engineered.

Open Source projects are motivated by ego in some cases ("I want to bulid the next great window manager") or some sense of technical correctness in others ("I hate the way OpenOffice looks/I hate Gtk widgets/etc."). So there's no real incentive to work together on a bigger project - why would you want to say "yeah, I built some tiny component that's part of this megalithic Open Source project, UltraOffice" when you can say "I am the lead programmer on KWord".

So knock closed source software all you will, money can be an effective way to motivate people to cooperate on bigger software tasks and put differences aside to achieve an overall better result. And though some Open Source business models make this possible, for lots of products (like office suites), nobody yet has figured out how to do this and it very well may be impossible.

Too hard to get started

[SurfsUp]

"In this interview with the KOffice development team it is revealed that only about 4-6 people are working on the suite of applications.

Yes, well I know exactly why that is. A few years ago I decided to hack kmail a little, until I found I had to build pretty much all of kde from source to do it. As opposed to installing the -devel headers as you would for more developer-friendly applications, then just untarring, ./configure, make. This stopped me, I see no reason why it wouldn't stop lots of folks.

Casual hacking is the way to get started on a project, it's wrong to require a whole huge cvs import and hours of mucking around with scripts trying to get the thing to build. Once you start with the casual hacking and submit a few patches, it's much easier to justify the effort to get in all the way and sync up to cvs.

If the koffice team wants more helpers, then they should put the effort into making it easier to get started. That means writing some scripts to pull tarballs out of cvs and hacking together some autoconf stuff. This effort will for sure pay off. People will start sending patches, and after a while some of them will get involved in a more hardcore way.

Look, why are the 1,000's of people hacking the Linux kernel tree? Because you can just grab the tarball and build it, no fuss no muss. Only super-hardcore developers or paid employees are going to get into a project by syncing to the cvs from the word go.

David, bless him, didn't get this 3 years ago, I hope he'll think about it now.

Re:[Small groups are ] Gibberish

[swb]

I wonder how the small v. large debate is influenced by management philosophies and organization.

In the limited experience I've had with software development one of the biggest limitations on software development was that merely adequate developers slowed down the really good developers. Projects couldn't continue forward until certain development milestones were met, so good people just kind of shut down.

This effect was magnified by well-intentioned managers. They wouldn't do anything to try to improve the laggards development skills or pacing because they were otherwise meeting the basic goals, were likeable people, and so on. The lack of vulnerability of the laggards also prevented the better developers from taking over the laggards projects or assisting their speedy completion, since the laggards had a sense of ownership and management "backing" which enabled them to maintain control of their segments in spite of the overall degredation of the project.

It leads me to wonder if development groups have ever applied a 6-Sigma style management process where the laggards were cut and new people brought in. I understand there's some risk -- new people slow everything down getting up to speed, but it has the potential advantage that it eliminates *known* hindrances, and its not an attempt to increase team sizes. In other words, you're trying to fix the team not make it bigger, hopefully avoiding some of the Man-Month style diminishing returns.