|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Saturday, 25 September 1999||Author: Kevin Lyda|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
On Tempests and Licenses
This article originated in osOpinion and is provided under the OpenContent License.
Corel is violating the GPL. That's the quicktake; the long term is that they will honor it. So "yeay! GPL!" but why aren't we pointing out that violating a license is actually the least of their mistakes?...
Obviously this is collision of cultures. But so far the debate has focused solely on Corel violating the license and it's bad for "the community." It is bad for us, but what no one seems to touch on is that it's bad for Corel too. Not in a PR way, but in terms of software quality and time to market.
This is a point that needs to be hammered home to Corel and the media. If Corel is using free software they don't just get code, they get living code. For each free software package they get a developer or group of developers committed to making that package the best it can be. It is *theirs*, and they don't want it to suck. If package frob has a bug, the developer responsible for it wants it to not have bugs and they want any bugs to go away yesterday.
That's why free software is better then the alternative. And Corel has the ability to leverage that. Now why aren't they?
Again it's pretty obvious, just like Linus, Corel doesn't scale. So they're applying their past experience with closed software and using a closed beta program. It's a bad move from a license perspective but it's even worse from a business perspective.
So what can Corel do to help themselves scale to the herd of cats that is the free software community? OK, let me put on my Director of Development at Corel hat on. Looking spiffy, I wonder if it will help me understand the icing penalty in hockey?
OK, so here I am. I want bug reports, I want some patches, but I don't want a deluge of them. I have x number of employees and the free software community is probably two orders of magnitude larger. I can't just read bug reports and patches, I have to farm them out to my team to be worked on. So initially I decide to send the distribution out to a small number of people. An amount I can deal with without quivering in an info-overload mass of nervous humanity.
So far I've done good, and I've done what Corel's done. But I'll avoid the license issue. See, my beta license agreement will allow free redistribution. Anyone can snatch the software and redistribute it to their bug hunting friends. But only beta testers can report bugs. And obviously I'll either restrict the software Corel has written that's not GPL-encumbered, or do some "time limit thing" to it. Also, beta testers will have to agree to having their email address published so that other developers can mail them with their bugs.
Maybe I'll even set up a web page where beta testers can say what they're focusing on. "I'm Jane and I'm a sendmail and MUA goddess, I'm focusing on mail issues. If you have a problem with mail (MUA or MTA) let me know and I'll pass it on to Corel."
And when the beta cycle ends, Corel and myself will offer beta testers free (or almost free, depends on the budget) copies of Corel Linux. I'll have leveraged free software for not only the code, but for system testing as well. I'll be a god and I'll use my leverage to get a chance to play goalie for some distant NHL farm team here in Ireland and we'll win the O'Stanley Cup on my amazing play!
Or maybe not. OK, the hockey thing just won't work, but give a thought to the beta test reworking folks. Corel isn't hurting us with this, they're hurting themselves. Let's make sure they figure that out and help us all reach our goal: "software that doesn't suck".