I disagree. The point is that you might be able to code a nice, very efficient voting system with cool features you don't want your competitors to *easily* replicate by copying your code.
Why isn't copyright protection sufficient for this, without closing the source?
Yes, under an OSS license a competitor will be be able to create a derived system -- but many non-BSD OSS licenses require those derived works to be open as well, and all require that credit be given to the copyright holder of the work from which the derivative was made. If you work for FooCorp and your competitor BarSoft is selling a derived work, they're required to acknowlege that their product contains code written by their FooCorp -- typically you can use that fact for sales purposes ("we originally wrote the code, we know it better and can support and extend it better -- ask BarSoft or examine the source yourself, we're the original author of these modules").
If BarSoft denies that their software is a derived work, they're breaking the license and so have no right to distribute their derived work -- so you can sue them for copyright infringement (and almost certainly prove that it's deliberate, and so win triple the losses they caused you).
Under those circumstances, I don't think that releasing your product as OSS is quite as harmful as you make it out to be.
Re:What were we eating then? [OTish]
on
Hackers On Atkins
·
· Score: 1
As far as why you're a foe, I couldn't tell you. But I trust my own judgment. I often mark as foes people whose opinions on hot issues I find to be irreconcilable with my own.
Just because I occasionally jump into a discussion on a topic I don't know (like this one) doesn't mean that opinions I may offer on topics I do know is less authoritative. But then, of course, perhaps that's just the sort of thing you may be usefully flagging via "Foe". *shrug*.
Hopefully my contribution to this discussion as a whole has been more useful (by eliciting your counterpoints) than counterproductive (by publicly espousing a position contradicted by evidence).
Satirize it all you like -- but I'd argue that deterministicly finding out what food is readily available to wild humans (by becoming one for a bit) is fairly deterministic -- as long as one has enough sampling points, of course. Which I don't -- but then, neither do you.
If you're going to argue that the actual diet is something different, I'd want to see some rather clear and convincing evidence (ie. an explanation of how the alternate figures were determined) before I'm going to accept it.
(BTW, did I earn that "foe" flag just by disagreeing with you once, or is there some more substantive explanation?)
Dumb bells and a weight bench are cheap, alternatively, you could just go for 30 minute walks. Avoid driving, when possible. Shitcan your pansy-assed Segway. Invest in a good bicycle.
I'm someone seriously considering the Atkins diet right now -- because the usual fixes just won't work for me right now. Note that the diet contains a "maintenance mode" plan (for keeping weight off long-term); it's not meant as a strictly short-term thing.
I do take 30-minute+ walks quite regularly, and never owned a Segway. On the other hand, a bicycle (which was my sole mode of transport in my old college town, where I was about 50 lbs lighter than I am now) is utterly useless where I'm currently living -- the city's just too spread out to get anywhere on one, the drivers to insane to risk being on the road with them, and there aren't any good bike trails within riding distance of my house. (There are some people who bike 360 -- the main highway between where I live and where I work -- but they're generally considered insane fitness-nut types; given the number and steepness of inclines on that route, I'd need a lot of training before I'd be ready for it -- plus an extra hour before and after work for travel time).
And anyhow -- between my full-time job (which has frequently involved all-nighters and, at a minimum, very long hours) and a half-time contract I'm considering, the traditional fitness mechanism just takes too damn much time.
Within these constraints, the Atkins route seems appropriate. It still requires some amount of inconveniance -- but not the massive time expendature that other routes to the same end require, nor will it strain my budget, and it's something I can actually do. (I'd also argue that, in this case, thinner is healthier, even in the absence of other benefits which a regimen heavier on exercise would provide).
Yup -- "market segmentation": They make one or more dirt cheap, low-quality products and one or more high-end, high-quality, expensive products -- and try not to advertise too hard that it's the same company making both (at least, when I bought a Sound Bug, I had no idea these were the folks involved).
So: I wouldn't cast doubts on the quality of the high-end product based on the lack of quality of the low-end product, since said lack of quality is almost certainly intentional.
First off, you're not understanding his point -- that most of the sales MS is claiming they would have made would not in fact have happened because other altetrnative products (OpenOffice, paper and pencil) would have been preferred over spending 4 months income on a piece of software. Because of this, MS's claimed losses are even more vastly overstated than is usually the case for numbers of that variety.
Second, it's typically in ones' economic advantage to contribute back changes made to GPLed software, because otherwise one can't upgrade to never versions without merging in the changes, a labor-intensive process.
They'll contribute their modifications back just like everyone else, and for the same economic reason: Maintaining their own branch of every piece of software they change is too damn expensive. Much cheaper and easier to submit your changes upstream and have other people maintain them for you.
Microsoft charges for their software a third of the average Vietnamese annual salary, which is a pretty stupid business move. But that doesn't change the fact that they lost a sale each time these people pirated their software instead of buying a legit copy.
You assume that the only alternative to pirating a copy is buying a legit copy at whatever price MS chooses, such that if the ability to pirate MS products is suddenly removed, everyone who pirated a copy would actually cough up the $140 a pop.
Rather than paying over 1/4 of ones' annual income for a piece of software, most people would rather do without (WordPad? the locally modified port of OpenOffice? Paper and pencil?).
So Microsoft lost a sale only each time one of these people pirated a copy who would otherwise have bought a copy legitimately. Given the price difference in question and the availability of alternatives, I can only see that as being very, very few people.
First-rate people hire first-rate people. Second-rate people hire third-rate people.
Ahh, but it's *sooo* true.
My workplace recently needed a new lead sysadmin. I reccomended one of the best sysadmin/system-level-programmer types I knew. Everyone who interviewed him agreed he was the best person we'd talked to -- except the VP of Engineering, who refused to hire him (but wouldn't say why).
Well, a few weeks go by, we haven't found anyone else who's up to snuff, so the VP gives in and hires this guy. Then the VP finds out that when he tries to micromanage system administration (and do things in order of visibility rather than dependency order) that the IT team actually starts *pushing back*, telling him exactly why his plans will take more time in the long run, require extra work, result in poorer service overall, etc etc.
The VP of Engineering no longer talks to the IT lead, or anyone else on IT if he can avoid it -- yet IT is dramatically more productive and provides better service to the engineering staff than was previously the case. Funny how that works, eh?
(And the other funny thing is that I don't really have a problem posting this here -- even if our dear VP of Engineering *does* find it. Frankly, I think I'd rather enjoy the outcome if he tried to fire me over this).
Of course there are some patents that issue that never get litigated, but then they dont have any effect on anyone.
Bullshit.
Someone tells me I'm infringing patent $FOO in a piece of Free Software I'm writing -- even if I think the patent was improperly granted, I don't have the money to litigate, so I remove the infringing functionality -- or, if that functionality is core, withdraw my program.
(Actually, that applies not just to Free Software -- most of the proprietary software development I'm involved in also has no budget allowance for litigation).
I'd call that a pretty damned chilling effect. Even worse is the threat of unintentional infringement -- that a solution I just happened to come up with for some problem just happens to be the same solution someone else came up with. That's something the standard of "obvious to someone trained in the art" is supposed to prevent, but the vast number of visibly obvious software patents out there puts the lie to that claim. As a small software developer, therefore, someone with a huge patent portfolio (and there are plenty of such entities) could almost certainly find some patent of theirs I've unknowingly infringed on.
My best defense for this, of course, would be to patent my own ideas that I recognize as non-obvious and innovative (see the cscvs changeset algamation algorithm), but that's simply too expensive -- the process of doing the relevant research and paying the costs involved in filing for patents could easily double or triple my development costs, and still leaves me vulnerable to patents on ideas I've incorporated by organizations which have no interest in cross-licensing from my far smaller portfolio.
In my home state town and city governments can interface with the state system for vehicle registration as a service to their citizens. This software requires strict compliance to the state spec, and must be updated on the whim of legislators. By law if the town offers registration it cannot be denied to a citizen - even if a computer is broke or a bug is present. That means highly-available support. Additionally it means that software fixes frequently must be implemented within 36 or 72 hours. The state must approve the "inputs" and "outputs" of the software.
Sounds like an excellent place for OSS, with some provisios:
The software must be redesigned in such a way as to make state-specific rulesets [the business logic] completely scriptable (ideally in a high-level language such as Python).
The process for writing state-specific rulesets must be very well-documented.
The communications protocol between the hardware and software should be a separate, well-documented, pluggable layer.
This is a win for the states: They can hire someone (possibly local) to maintain and debug their ruleset as-needed, or have their in-house programming staff do the same. Alternately, they can hire someone (and possibly a rather big someone -- I've mentioned the Big Blue Gorilla elsewhere) to provide contracted support guarantees.
It's a win for competing hardware manufacturers. Right now there's a single source for this hardware, right? Same people who make the software, right? Commoditizing the hardware (by making the same software work with multiple hardware platforms) is a big win for non-entrenched players who think they could make the hardware cheaper, more reliable, or otherwise better -- but who have no chance in the market due to lock-in by the present vendor. Indeed, the most likely entity to start a project like this might be someone pondering entering the market selling competing hardware. (Another possibility is a government employee with some spare time after work).
The folks who lose are the people who presently own the non-commoditized software -- but if someone else (be it a state or be it a hardware manufacturer) decides it's in their economic interests to build an OSS replacement, are you seriously inclined to call them wrong?
However, your claim that you couldnt lock clients in is false. Unless you are working in a field of drop-in transparent components, it costs clients to port to a new toolkit, platform, or environment. Thats the truth.
Of course it costs money to port to a different solution -- but part of the point of OSS is that a customer can switch providers without switching solutions. So no -- no vendor lock in.
OSS software is getting more complex, more crufty, and less sparsley documentated[...]
That's a strong claim you're making. Think you can back that up?
I've been dealing with OSS for quite a while -- and I can say that it is unequivocably simpler to set up a single system or a whole lab or cluster than it was 5 years ago. Hardware detection Does The Right Thing, auto-install systems Just Work, application software is *tremendously* polished compared to what it was. Look at Eclipse, or GNOME, or Red Hat's Kickstart process, and then compare them to their 5-year-ago equivalents if you have questions on this point.
Unless you can provide hard evidence, I'm going to have to call bullshit on that one.
A company without a programmer hiring a consultant to modify or make use of an OSS product would be making a very bad business decision. It'd be far more expensive in virtually all circumstances.
Not if the alternative is hiring a consultant to modify or make use of an in-house commercial product. I've worked at companies without in-house programming staff who nonetheless owned and used their own proprietary product. When t
Err, you do realize that the "Java Desktop" is just what Sun is calling their desktop environment (consisting of Gnome, Evolution, and the like) which really has very little to do with Java at all?
Selling support and consulting as a living is a bad thing for OSS. That will guide OSS development. Whereas commerical companies see support as a cost burden OSS companies will see it as revenue. Commerical software will continue to focus on ways to make it so that support is rare and painless. OSS will continue to become more archane, more complex, and less likely to be self-managing. This is only going to turn people away. Whats the good of OSS software if it is so complex or costly in support or unwieldy. You might as well buy OSS.
Let's focus on what does happen as opposed to what we think might happen, eh?
My last employer, MontaVista Software, made their primary revenue from selling a development toolkit for embedded systems work composed of open source software, along with related services and support. Intentionally making our software "more arcane, complex and less likely to be self-managing" would have been suicide -- because we would have lost business to our competitors, either open source (such as Lineo) or closed source (like Wind River). In fact, because the open license permitted our customers to switch to a different supplier at will while still using the same software we provided, we had to work damn hard to keep them -- and we did.
If nothing else, this inability to lock in customers is a powerful means of keeping OSS providers honest and customer-focused rather than seeking artificial ways of boosting revenue.
Finally, remember that support still is a cost center for OSS maintainers. "Huh?" you say, "They're selling consulting". Well, sure -- to businesses that want enhancements. On the other hand, any respectable maintainer will very quickly get fed up with the constant user whining that goes on if their service needs to be restarted all the time, or has utterly unusable documentation, or whatever; most maintainers would also *far* rather be paid to do feature enhancements than play tech support, even if some of the tech support pays -- and that means keeping support requests to an absolute minimum. Finally, if someone's software is visibly fragile or poorly designed, it's all the much more likely that someone else's solution (or fork!) will overtake them.
(And by the way, when I say "most maintainers", I'm speaking from experience. I currently maintain two OSS projects, and have done substantial amounts of work on far more).
But lets imagine this. Lets imagine the software you wrote was available commerically for a few hundred bucks, and it did exactly what your company wanted. Would they still have spent money to have you write it?
Let's see... me spending two days on a project modifying previously available open source software to do what we needed, as opposed to paying a few hundred bucks per workstation... yup, I think they'd take it.
Additionally, "giving it away" was not a "feel-good" decision; it's something we did because the easiest way to get this thing written was to use preexisting 3rd-party code licensed under the GPL. Otherwise all that code would have had to have been written ground-up or commercially licensed -- and neither one of those is cheap.
Software that controls printing presses, machines, vertical business functions, etc are going to stay and remain proprietary forever.
Most of these I'll agree with you on, but here's the catch:
Just about all of this software contains components which are in practice commodities. Machine control software includes software to do silly low-level things like timing, statistical analysis, serial line control, menu drawing, plotting; as commodity-level software, these components are prime candidates for release as open source. Anybody writing typesetting software these days and trying to get it done on a tight budget would be insane not to use TeX as their base. As for vertical business functions -- ther
Jeesh, you're the second person (whom one would expect to be a geek) I've run into lately who hasn't known what a dongle is. Flippin' newbies.:)
A dongle, for those who weren't around in the late 80s/early 90s (when they were in heavy use on expensive commercial software), is a device that attaches to a parallel port to unlock a chunk of code. Some of the most clever/expensive ones actually keep bits of the program logic inside the dongle (to make it difficult to crack), but this is very rare; more usually, it's just a serial number and a few bytes of data to determine what product (or what product *features*) the user has purchased a license for.
AutoCAD, the more expensive 3D rendering packages... most commercial software running over a few hundred $$ would come with dongles. (Real PITA in a public lab, btw, where the dongles would be frequently stolen so that folks could run their pirate copies of the software in question).
If you can't afford it, either it's bad enough for the emergency room as soon as it happens or you (usually) can manage to get along just fine with home remedies, over-the-counter medicines and the like without it getting bad enough for the emergency room at all.
I've been living without health insurance for quite a long while now (and I'm employed by a company making medical software) -- and have yet to find myself in a situation that's overly unworkable. That said, though, I don't have a family[*] -- if I did, medical insurance would be not nice-to-have but essential.
Well, for one thing, the question isn't whether chemical $FOO exists -- the question is whether the smell is too bad (where "too bad" is defined as "detectable at 1/7 concentration").
Even having results on which chemicals exist in the air and in what amounts doesn't necessarily answer whether that smell is sufficiently offensive to the nose as to be a legal violation -- and I'd be unsuprised if translating between the two is a hard problem on par with determining which sounds (out of a set which are being played at once) people will actually perceive: Solvable, yes, but not without a lot of expensive research.
So you will see an OSS developer set up a system. During the honeymoon, they laud their moral superiority to property owners, but when the difficult maintenance issues come along, they come out saying: "Well, I am the only one who knows the root password, and I charge $xxx.00 per hour."
I've never seen anyone do that, and I'd consider them scum if they did. Part of the selling points of OSS is that the customer can switch providers if they need to -- locking them in artificially is a dirty, cheap thing to do.
And anyhow, I'm not at all sure that's a situation at all related to open source -- I've seen exactly the same thing happen with proprietary software which was (supposedly) a work-for-hire and owned by customer. Scum is scum, be their licensing open or proprietary; that said, though, I doubt very much that there's more of them to be found on the OSS side of the fence.
The fact remains that writing software and giving it away has yet to be proven as a longtime viable industry.
I don't think it is. In fact, I think it's a damn stupid idea to start a business on.
On the other hand, if you're making widgets -- particularly widgets which are really a hardware item with some software built in -- it makes a lot of sense to use Free Software. After all, what you're selling isn't the software, it's the widget. The software is a necessary component, sure -- but what it really is is a cost center. If you've got the choice between making your own software or contributing to a project by which the costs are shared, even with your competitors -- unless you've got vastly more funds than your competitors have, it's in your advantage to play.
Now, let's say you no longer make hardware widgets. Let's say you produce software -- that your customers get shipped a generic box that anyone could buy that has some software you spent a lot of time and money to create that is the only thing that makes the box valuable. In that case, making that software itself open source would be a really Dumb Idea.
On the other hand... what development tools did you use to create the software on that box? Wouldn't it be great if instead of spending $1K per developer you could just have one of your in-house guys customize or improve an open source project to make it suitable for your use?
What operating system are you shipping on that box? How much are you spending per-unit on that OS? If you don't have the engineering talent in-house to make your own or to customize a previously existing open source OS -- why not pay someone who does have that talent to do it for you? There's still a compelling business argument for you, the manufacturer of a box which ships with expensive software -- you don't want to pay a royalties, and if you're paying someone else to do the OSS work for you, you may pay quite a bit up-front, but there won't be any royalties required. [Replace "operating system" with "application server" or "database" or any other piece of underlying software, and the argument in this paragraph still holds].
Now, let's say you sell custom hardware and a custom, proprietary UNIX. Now, let's say you want a new GUI environment -- perhaps the one you were using earlier is a bit too old and crufty. Suddenly, you can roll your own commercial solution, buy a preexisting commercial solution... or use an open source one that's available. You go with open source, and you're spending a lot less than you'd pay if you rolled your own -- plus you're getting something that already has applications and users who're familiar with it. You can still sell your proprietary UNIX and the hardware that comes with it -- you're just spending less on the GUI.
And so forth. There's a compelling argument for businesses not to make OSS their sole purpose of existing, but rather to use it to reduce their costs -- and as more businesses who are using OSS to reduce their costs decide to outsource customization and support of the OSS they use, there's an increasing role for companies to do these modifications and customizations.
Finally, a thought: Just because my company doesn't have any cheques coming in from the open source Kerberos ticket-tracking applet I wrote at work, doesn't mean that it hasn't made them more money than it cost them for me to write it -- it's made internal support dramatically easier now that users no longer have weird things suddenly happen to them when their ticket expires. Further, because it's open source (1) I was able to write it faster because I was able to derive it from sources which otherwise would have been unavailable without the lengthy process of getting permission from their owners, and (2) there are 3rd party contributions -- the author of Shishi (an alternate Kerberos implementation) has, for instance, submitted a patch adding support for non-MIT Kerberos implementations; this means that should we ever have a good busine
Oooh, the poor buggy whip manufacturers! Think of the unemployment costs! Except that making cars still employes people. A lot of people.
Making widgets employes people too. Now, maybe those widgets hava a software component -- frequently they do these days. If a widget manufacturer can save money by hiring two programmers to modify, maintain and debug an open source widget control package rather than just buying a commercial package from a company that employs 20 people -- oh, woe is me! We're putting the company that makes the commercial package out of business!
Except that widgets get cheaper (customers win), the company's expenses go down and let them hire more people (the extra widget specialist who's now got a job wins), they have in-house tech support for solving software products with their widgets faster than the supplier would (customers win) and one or two OSS guys per widget manufacturering shop may end up turn up to be more employed programmers than the commercial widget control package employed in the first place!
The simplistic view that OSS destroys jobs is just that -- simplistic. OSS may create jobs. OSS may destroy jobs. OSS may result in an increase in the number of jobs in general but a decrease in the number of jobs in software. You don't have the ability to answer these questions conclusively, and I don't either -- so get down off your high horse and quit spreading FUD.
Their contract specified that the source was held in escrow and that they'd get the copy of it -- and the keygenerator -- if the company they purchased it from went out of business. Whoever buys rights to that source would have a very hard time explaining why they're prosecuting someone for cracking a piece of software that their predecessor in interest was legally obliged to give out a keygenerator for anyhow.
I do not know a single open source developer who has had trouble finding work even in the previous bad economy.
Actually, I've known two very skilled OSS developers who've had substantial trouble finding work within the last year or so. One of them is now employed, and I'm not going to identify him here. The other is Tom Lord, the primary author of Arch, a next-generation revision control system. (If you're thinking of switching from CVS to BitKeeper or Subversion, go look into Arch. Now). Tom's been out of work quite a good long while, despite being one of the best UNIX developer/architects I know. Part of this is his location in the Bay Area (indeed, I got him a job offer contingent on his willingness to move to Texas and he declined).
Anyhow, just because the economy's getting better in a lot of places doesn't mean that we're quite there to the point where anyone who does something valuable and is very good at what they do is employed -- but then, we're certainly getting back there.
Slashdot Mirror
I disagree. The point is that you might be able to code a nice, very efficient voting system with cool features you don't want your competitors to *easily* replicate by copying your code.
Why isn't copyright protection sufficient for this, without closing the source?
Yes, under an OSS license a competitor will be be able to create a derived system -- but many non-BSD OSS licenses require those derived works to be open as well, and all require that credit be given to the copyright holder of the work from which the derivative was made. If you work for FooCorp and your competitor BarSoft is selling a derived work, they're required to acknowlege that their product contains code written by their FooCorp -- typically you can use that fact for sales purposes ("we originally wrote the code, we know it better and can support and extend it better -- ask BarSoft or examine the source yourself, we're the original author of these modules").
If BarSoft denies that their software is a derived work, they're breaking the license and so have no right to distribute their derived work -- so you can sue them for copyright infringement (and almost certainly prove that it's deliberate, and so win triple the losses they caused you).
Under those circumstances, I don't think that releasing your product as OSS is quite as harmful as you make it out to be.
As far as why you're a foe, I couldn't tell you. But I trust my own judgment. I often mark as foes people whose opinions on hot issues I find to be irreconcilable with my own.
Just because I occasionally jump into a discussion on a topic I don't know (like this one) doesn't mean that opinions I may offer on topics I do know is less authoritative. But then, of course, perhaps that's just the sort of thing you may be usefully flagging via "Foe". *shrug*.
Hopefully my contribution to this discussion as a whole has been more useful (by eliciting your counterpoints) than counterproductive (by publicly espousing a position contradicted by evidence).
Satirize it all you like -- but I'd argue that deterministicly finding out what food is readily available to wild humans (by becoming one for a bit) is fairly deterministic -- as long as one has enough sampling points, of course. Which I don't -- but then, neither do you.
If you're going to argue that the actual diet is something different, I'd want to see some rather clear and convincing evidence (ie. an explanation of how the alternate figures were determined) before I'm going to accept it.
(BTW, did I earn that "foe" flag just by disagreeing with you once, or is there some more substantive explanation?)
Dumb bells and a weight bench are cheap, alternatively, you could just go for 30 minute walks. Avoid driving, when possible. Shitcan your pansy-assed Segway. Invest in a good bicycle.
I'm someone seriously considering the Atkins diet right now -- because the usual fixes just won't work for me right now. Note that the diet contains a "maintenance mode" plan (for keeping weight off long-term); it's not meant as a strictly short-term thing.
I do take 30-minute+ walks quite regularly, and never owned a Segway. On the other hand, a bicycle (which was my sole mode of transport in my old college town, where I was about 50 lbs lighter than I am now) is utterly useless where I'm currently living -- the city's just too spread out to get anywhere on one, the drivers to insane to risk being on the road with them, and there aren't any good bike trails within riding distance of my house. (There are some people who bike 360 -- the main highway between where I live and where I work -- but they're generally considered insane fitness-nut types; given the number and steepness of inclines on that route, I'd need a lot of training before I'd be ready for it -- plus an extra hour before and after work for travel time).
And anyhow -- between my full-time job (which has frequently involved all-nighters and, at a minimum, very long hours) and a half-time contract I'm considering, the traditional fitness mechanism just takes too damn much time.
Within these constraints, the Atkins route seems appropriate. It still requires some amount of inconveniance -- but not the massive time expendature that other routes to the same end require, nor will it strain my budget, and it's something I can actually do. (I'd also argue that, in this case, thinner is healthier, even in the absence of other benefits which a regimen heavier on exercise would provide).
Here's a little experiment.
Go spent two weeks out of doors with no supplies. See what you can find to eat.
Last person I knew to do this ended up subsisting *mostly* on small game (and got to be extremely good at throwing rocks).
Yup -- "market segmentation": They make one or more dirt cheap, low-quality products and one or more high-end, high-quality, expensive products -- and try not to advertise too hard that it's the same company making both (at least, when I bought a Sound Bug, I had no idea these were the folks involved).
So: I wouldn't cast doubts on the quality of the high-end product based on the lack of quality of the low-end product, since said lack of quality is almost certainly intentional .
First off, you're not understanding his point -- that most of the sales MS is claiming they would have made would not in fact have happened because other altetrnative products (OpenOffice, paper and pencil) would have been preferred over spending 4 months income on a piece of software. Because of this, MS's claimed losses are even more vastly overstated than is usually the case for numbers of that variety.
Second, it's typically in ones' economic advantage to contribute back changes made to GPLed software, because otherwise one can't upgrade to never versions without merging in the changes, a labor-intensive process.
They'll contribute their modifications back just like everyone else, and for the same economic reason: Maintaining their own branch of every piece of software they change is too damn expensive. Much cheaper and easier to submit your changes upstream and have other people maintain them for you.
Microsoft charges for their software a third of the average Vietnamese annual salary, which is a pretty stupid business move. But that doesn't change the fact that they lost a sale each time these people pirated their software instead of buying a legit copy.
You assume that the only alternative to pirating a copy is buying a legit copy at whatever price MS chooses, such that if the ability to pirate MS products is suddenly removed, everyone who pirated a copy would actually cough up the $140 a pop.
Rather than paying over 1/4 of ones' annual income for a piece of software, most people would rather do without (WordPad? the locally modified port of OpenOffice? Paper and pencil?).
So Microsoft lost a sale only each time one of these people pirated a copy who would otherwise have bought a copy legitimately. Given the price difference in question and the availability of alternatives, I can only see that as being very, very few people.
Only if the source isn't available on request -- it doesn't need to be on the CD.
First-rate people hire first-rate people. Second-rate people hire third-rate people.
Ahh, but it's *sooo* true.
My workplace recently needed a new lead sysadmin. I reccomended one of the best sysadmin/system-level-programmer types I knew. Everyone who interviewed him agreed he was the best person we'd talked to -- except the VP of Engineering, who refused to hire him (but wouldn't say why).
Well, a few weeks go by, we haven't found anyone else who's up to snuff, so the VP gives in and hires this guy. Then the VP finds out that when he tries to micromanage system administration (and do things in order of visibility rather than dependency order) that the IT team actually starts *pushing back*, telling him exactly why his plans will take more time in the long run, require extra work, result in poorer service overall, etc etc.
The VP of Engineering no longer talks to the IT lead, or anyone else on IT if he can avoid it -- yet IT is dramatically more productive and provides better service to the engineering staff than was previously the case. Funny how that works, eh?
(And the other funny thing is that I don't really have a problem posting this here -- even if our dear VP of Engineering *does* find it. Frankly, I think I'd rather enjoy the outcome if he tried to fire me over this).
Of course there are some patents that issue that never get litigated, but then they dont have any effect on anyone.
Bullshit.
Someone tells me I'm infringing patent $FOO in a piece of Free Software I'm writing -- even if I think the patent was improperly granted, I don't have the money to litigate, so I remove the infringing functionality -- or, if that functionality is core, withdraw my program.
(Actually, that applies not just to Free Software -- most of the proprietary software development I'm involved in also has no budget allowance for litigation).
I'd call that a pretty damned chilling effect. Even worse is the threat of unintentional infringement -- that a solution I just happened to come up with for some problem just happens to be the same solution someone else came up with. That's something the standard of "obvious to someone trained in the art" is supposed to prevent, but the vast number of visibly obvious software patents out there puts the lie to that claim. As a small software developer, therefore, someone with a huge patent portfolio (and there are plenty of such entities) could almost certainly find some patent of theirs I've unknowingly infringed on.
My best defense for this, of course, would be to patent my own ideas that I recognize as non-obvious and innovative (see the cscvs changeset algamation algorithm), but that's simply too expensive -- the process of doing the relevant research and paying the costs involved in filing for patents could easily double or triple my development costs, and still leaves me vulnerable to patents on ideas I've incorporated by organizations which have no interest in cross-licensing from my far smaller portfolio.
Sounds like an excellent place for OSS, with some provisios:
This is a win for the states: They can hire someone (possibly local) to maintain and debug their ruleset as-needed, or have their in-house programming staff do the same. Alternately, they can hire someone (and possibly a rather big someone -- I've mentioned the Big Blue Gorilla elsewhere) to provide contracted support guarantees.
It's a win for competing hardware manufacturers. Right now there's a single source for this hardware, right? Same people who make the software, right? Commoditizing the hardware (by making the same software work with multiple hardware platforms) is a big win for non-entrenched players who think they could make the hardware cheaper, more reliable, or otherwise better -- but who have no chance in the market due to lock-in by the present vendor. Indeed, the most likely entity to start a project like this might be someone pondering entering the market selling competing hardware. (Another possibility is a government employee with some spare time after work).
The folks who lose are the people who presently own the non-commoditized software -- but if someone else (be it a state or be it a hardware manufacturer) decides it's in their economic interests to build an OSS replacement, are you seriously inclined to call them wrong?
Of course it costs money to port to a different solution -- but part of the point of OSS is that a customer can switch providers without switching solutions . So no -- no vendor lock in.
That's a strong claim you're making. Think you can back that up?
I've been dealing with OSS for quite a while -- and I can say that it is unequivocably simpler to set up a single system or a whole lab or cluster than it was 5 years ago. Hardware detection Does The Right Thing, auto-install systems Just Work, application software is *tremendously* polished compared to what it was. Look at Eclipse, or GNOME, or Red Hat's Kickstart process, and then compare them to their 5-year-ago equivalents if you have questions on this point.
Unless you can provide hard evidence, I'm going to have to call bullshit on that one.
Not if the alternative is hiring a consultant to modify or make use of an in-house commercial product. I've worked at companies without in-house programming staff who nonetheless owned and used their own proprietary product. When t
Err, you do realize that the "Java Desktop" is just what Sun is calling their desktop environment (consisting of Gnome, Evolution, and the like) which really has very little to do with Java at all?
Let's focus on what does happen as opposed to what we think might happen, eh?
My last employer, MontaVista Software, made their primary revenue from selling a development toolkit for embedded systems work composed of open source software, along with related services and support. Intentionally making our software "more arcane, complex and less likely to be self-managing" would have been suicide -- because we would have lost business to our competitors, either open source (such as Lineo) or closed source (like Wind River). In fact, because the open license permitted our customers to switch to a different supplier at will while still using the same software we provided, we had to work damn hard to keep them -- and we did.
If nothing else, this inability to lock in customers is a powerful means of keeping OSS providers honest and customer-focused rather than seeking artificial ways of boosting revenue.
Finally, remember that support still is a cost center for OSS maintainers. "Huh?" you say, "They're selling consulting". Well, sure -- to businesses that want enhancements. On the other hand, any respectable maintainer will very quickly get fed up with the constant user whining that goes on if their service needs to be restarted all the time, or has utterly unusable documentation, or whatever; most maintainers would also *far* rather be paid to do feature enhancements than play tech support, even if some of the tech support pays -- and that means keeping support requests to an absolute minimum. Finally, if someone's software is visibly fragile or poorly designed, it's all the much more likely that someone else's solution (or fork!) will overtake them.
(And by the way, when I say "most maintainers", I'm speaking from experience. I currently maintain two OSS projects, and have done substantial amounts of work on far more).
Let's see... me spending two days on a project modifying previously available open source software to do what we needed, as opposed to paying a few hundred bucks per workstation... yup, I think they'd take it.
Additionally, "giving it away" was not a "feel-good" decision; it's something we did because the easiest way to get this thing written was to use preexisting 3rd-party code licensed under the GPL. Otherwise all that code would have had to have been written ground-up or commercially licensed -- and neither one of those is cheap.
Most of these I'll agree with you on, but here's the catch:
Just about all of this software contains components which are in practice commodities. Machine control software includes software to do silly low-level things like timing, statistical analysis, serial line control, menu drawing, plotting; as commodity-level software, these components are prime candidates for release as open source. Anybody writing typesetting software these days and trying to get it done on a tight budget would be insane not to use TeX as their base. As for vertical business functions -- ther
Jeesh, you're the second person (whom one would expect to be a geek) I've run into lately who hasn't known what a dongle is. Flippin' newbies. :)
A dongle, for those who weren't around in the late 80s/early 90s (when they were in heavy use on expensive commercial software), is a device that attaches to a parallel port to unlock a chunk of code. Some of the most clever/expensive ones actually keep bits of the program logic inside the dongle (to make it difficult to crack), but this is very rare; more usually, it's just a serial number and a few bytes of data to determine what product (or what product *features*) the user has purchased a license for.
AutoCAD, the more expensive 3D rendering packages... most commercial software running over a few hundred $$ would come with dongles. (Real PITA in a public lab, btw, where the dongles would be frequently stolen so that folks could run their pirate copies of the software in question).
If you can't afford it, either it's bad enough for the emergency room as soon as it happens or you (usually) can manage to get along just fine with home remedies, over-the-counter medicines and the like without it getting bad enough for the emergency room at all.
I've been living without health insurance for quite a long while now (and I'm employed by a company making medical software) -- and have yet to find myself in a situation that's overly unworkable. That said, though, I don't have a family[*] -- if I did, medical insurance would be not nice-to-have but essential.
[*] - but don't tell my housemates' kids that.
Well, for one thing, the question isn't whether chemical $FOO exists -- the question is whether the smell is too bad (where "too bad" is defined as "detectable at 1/7 concentration").
Even having results on which chemicals exist in the air and in what amounts doesn't necessarily answer whether that smell is sufficiently offensive to the nose as to be a legal violation -- and I'd be unsuprised if translating between the two is a hard problem on par with determining which sounds (out of a set which are being played at once) people will actually perceive: Solvable, yes, but not without a lot of expensive research.
Wasn't that the E, or otherwise one of the later models, where that feature was introduced? It's the original Enterprise they're testing here.
nt == "no text"
So you will see an OSS developer set up a system. During the honeymoon, they laud their moral superiority to property owners, but when the difficult maintenance issues come along, they come out saying: "Well, I am the only one who knows the root password, and I charge $xxx.00 per hour."
I've never seen anyone do that, and I'd consider them scum if they did. Part of the selling points of OSS is that the customer can switch providers if they need to -- locking them in artificially is a dirty, cheap thing to do.
And anyhow, I'm not at all sure that's a situation at all related to open source -- I've seen exactly the same thing happen with proprietary software which was (supposedly) a work-for-hire and owned by customer. Scum is scum, be their licensing open or proprietary; that said, though, I doubt very much that there's more of them to be found on the OSS side of the fence.
The fact remains that writing software and giving it away has yet to be proven as a longtime viable industry.
I don't think it is. In fact, I think it's a damn stupid idea to start a business on.
On the other hand, if you're making widgets -- particularly widgets which are really a hardware item with some software built in -- it makes a lot of sense to use Free Software. After all, what you're selling isn't the software, it's the widget. The software is a necessary component, sure -- but what it really is is a cost center. If you've got the choice between making your own software or contributing to a project by which the costs are shared, even with your competitors -- unless you've got vastly more funds than your competitors have, it's in your advantage to play.
Now, let's say you no longer make hardware widgets. Let's say you produce software -- that your customers get shipped a generic box that anyone could buy that has some software you spent a lot of time and money to create that is the only thing that makes the box valuable. In that case, making that software itself open source would be a really Dumb Idea.
On the other hand... what development tools did you use to create the software on that box? Wouldn't it be great if instead of spending $1K per developer you could just have one of your in-house guys customize or improve an open source project to make it suitable for your use?
What operating system are you shipping on that box? How much are you spending per-unit on that OS? If you don't have the engineering talent in-house to make your own or to customize a previously existing open source OS -- why not pay someone who does have that talent to do it for you? There's still a compelling business argument for you, the manufacturer of a box which ships with expensive software -- you don't want to pay a royalties, and if you're paying someone else to do the OSS work for you, you may pay quite a bit up-front, but there won't be any royalties required. [Replace "operating system" with "application server" or "database" or any other piece of underlying software, and the argument in this paragraph still holds].
Now, let's say you sell custom hardware and a custom, proprietary UNIX. Now, let's say you want a new GUI environment -- perhaps the one you were using earlier is a bit too old and crufty. Suddenly, you can roll your own commercial solution, buy a preexisting commercial solution... or use an open source one that's available. You go with open source, and you're spending a lot less than you'd pay if you rolled your own -- plus you're getting something that already has applications and users who're familiar with it. You can still sell your proprietary UNIX and the hardware that comes with it -- you're just spending less on the GUI.
And so forth. There's a compelling argument for businesses not to make OSS their sole purpose of existing, but rather to use it to reduce their costs -- and as more businesses who are using OSS to reduce their costs decide to outsource customization and support of the OSS they use, there's an increasing role for companies to do these modifications and customizations.
Finally, a thought: Just because my company doesn't have any cheques coming in from the open source Kerberos ticket-tracking applet I wrote at work, doesn't mean that it hasn't made them more money than it cost them for me to write it -- it's made internal support dramatically easier now that users no longer have weird things suddenly happen to them when their ticket expires. Further, because it's open source (1) I was able to write it faster because I was able to derive it from sources which otherwise would have been unavailable without the lengthy process of getting permission from their owners, and (2) there are 3rd party contributions -- the author of Shishi (an alternate Kerberos implementation) has, for instance, submitted a patch adding support for non-MIT Kerberos implementations; this means that should we ever have a good busine
Oooh, the poor buggy whip manufacturers! Think of the unemployment costs! Except that making cars still employes people. A lot of people.
Making widgets employes people too. Now, maybe those widgets hava a software component -- frequently they do these days. If a widget manufacturer can save money by hiring two programmers to modify, maintain and debug an open source widget control package rather than just buying a commercial package from a company that employs 20 people -- oh, woe is me! We're putting the company that makes the commercial package out of business!
Except that widgets get cheaper (customers win), the company's expenses go down and let them hire more people (the extra widget specialist who's now got a job wins), they have in-house tech support for solving software products with their widgets faster than the supplier would (customers win) and one or two OSS guys per widget manufacturering shop may end up turn up to be more employed programmers than the commercial widget control package employed in the first place!
The simplistic view that OSS destroys jobs is just that -- simplistic. OSS may create jobs. OSS may destroy jobs. OSS may result in an increase in the number of jobs in general but a decrease in the number of jobs in software. You don't have the ability to answer these questions conclusively, and I don't either -- so get down off your high horse and quit spreading FUD.
Their contract specified that the source was held in escrow and that they'd get the copy of it -- and the keygenerator -- if the company they purchased it from went out of business. Whoever buys rights to that source would have a very hard time explaining why they're prosecuting someone for cracking a piece of software that their predecessor in interest was legally obliged to give out a keygenerator for anyhow.
I do not know a single open source developer who has had trouble finding work even in the previous bad economy.
Actually, I've known two very skilled OSS developers who've had substantial trouble finding work within the last year or so. One of them is now employed, and I'm not going to identify him here. The other is Tom Lord, the primary author of Arch, a next-generation revision control system. (If you're thinking of switching from CVS to BitKeeper or Subversion, go look into Arch. Now). Tom's been out of work quite a good long while, despite being one of the best UNIX developer/architects I know. Part of this is his location in the Bay Area (indeed, I got him a job offer contingent on his willingness to move to Texas and he declined).
Anyhow, just because the economy's getting better in a lot of places doesn't mean that we're quite there to the point where anyone who does something valuable and is very good at what they do is employed -- but then, we're certainly getting back there.