First let me say that I think that it is important to provide an emulation option for Windows servers in order to decrease the cost of migration. That being said-- Linux allows you do to things with your network that you couldn't even dream of doing on Windows.
Yeah, I wasn't discounting the need for emulation as an aid in migration. What concerns me is that too often the focus seems to only be on emulation when there is so much more possible.
I've set up Samba + LDAP to serve Windows clients using Debian. Unfortunately, in this case, it takes a whole lot longer because nobody thus far has seemed interested in writing a good Open Source tool to aid in making this work out of the box and to ongoing Samba administration less of a hastle. Setting up a small enterprise server with Debian feels a whole lot like building a microprocessor given a pile of sand. As a result, we have the market for SLES, RHE, and others. While there's nothing inherently wrong with this, it would be better to have one popular open source solution that everyone is familiar with instead of dozens of proprietary GUI tools packaged with the commercial distros. "Widget frosting" is not a sustainable OSS business model.
A major issue not mentioned in this article is the prevelence of Windows-only server-side software. Besides easier administration using AD, this is another significant reason why people stick with Windows Server in real life. They absolutely need their custom departmental business apps, so the choice of operating system becomes secondary. NOTE: This is why we need a strong focus on real-world F/OSS database applications. This is without question the killer app of Open Source in the enterprise. (Hint: big money here, and think Java)
One last thing not mentioned is the fact that the Windows server environment is not just about sharing files. Group policies, MSI, etc. are powerful tools for administering a Windows network that Samba does not provide. After all, Samba is only one piece of the puzzle. That's not to say that these solutions are ideal, but if you're stuck with a Windows environment, they become a valid factor to consider.
All things considered, we as the Open Source community should not be focusing on emulating Windows Server as the key to the enterprise. This is an endless game of catch up to unstable, proprietary standards. We need to aim higher. We should be innovating and re-thinking the current office computing paradigm. We need to make it attractive not only to replace Windows on the server but also on the desktop as a direct result of the benefits of a purely non-Windows environment. Those benefits can only materialize if we create our *own* enterprise solutions instead of trying to just become compatible with the status quo.
F/OSS software is generally software designed by geeks for use by geeks. I've seen a LOT of great sutff come out of it, but almost always, the person on the other end has been a techie first and foremost and an artist second.
Hah! That's a joke. It takes just as much time to learn Photoshop and Lightwave as it does to learn Gimp and Blender. People sometimes scoff at the new generation of F/OSS graphics software because it's not what they're used to. But I find it just as difficult to use Photoshop after years of using Gimp, so I can understand where they're coming from. The key is educating the next generation on F/OSS tools from the beginning so that we can finally move away from the rip-off proprietary standbys. At the rate that Gimp and Blender are improving, there will soon be no valid technical reason why they cannot be used even for the most professional of tasks. As for the UI side of things, it would be an interesting project to develop an alternative Gimp interface designed for current Photoshop users. It's more about familiar layout than anything. In the grand scheme of things, both free and non-free software needs a lot of work to improve in the HCI area..
Sadly, I fear the ideology might get in the way...
It's a difficult trade-off. If there was a stable way for hardware manufacturers to release binary Linux drivers, there would be a whole lot less incentive to give out specs / driver code among those who are half-hearted about supporting OSS. Sure, we might see almost all hardware supported in Linux, but almost none of the drivers would be open source.
I think the current scenario is the best balance for now. Those who play nice with the community have the least work to do and get the best results (and this also saves them a lot of money). Others who refuse to give out specs or code can still support Linux but there is a penalty for not doing things the proper way. In the past, there have been numerous companies that started out doing the binary-only thing and then realized that it just wasn't worth it and subsequently released the sources.
Ultimately, the answer is patent reform, specifically the formal barring of software patents by the USPTO. (they currently exist only in case law, not formal policy) Legal fears are the only reason why any company would be legitimately concerned about releasing detailed hardware specs or driver code. To date, this has really only significantly affected 3D video chipset manufacturers because of the vicious patenting of every nuance of functionality in this field. As a result, there is an absurd amount of cross-licensing and that involves agreements that cannot be easily worked around.
Does Linux still need a better driver model? Probably. (:
Because: 1.) you might not have actually paid for it otherwise, therefore the seller has lost no revenue. 2.) you might be using it for fair-use purposes, such as research, certain educational use, etc. 3.) you might be sampling it before buying
It's not a black-and-white issue, neither legally nor morally. If 1 through 3 apply, you're probably being dishonest. (as in, not holding up your end of the bargain) In the end, copyright is best seen as an enforced honor system. That is why it is traditionally an area of civil law. (you can sue people who have "broken the contract" and the courts decide if that is really the case) And this is the way it should remain. There are too many grey areas to go around automatically labelling potential copyright-infringers as criminals or "thieves". The only place where these labels clearly belong is applied to commercial counterfeiting operations where there is an explicit diversion of actual revenue from the rightful recipient.
Another way to look at the situation is to compare to a library. If you borrow a book from a library, read it all the way through, and then return it so someone else can do the same, are you 'stealing' from the author? Or what if you buy a book, read it, and then donate it to the library so that others can enjoy it for free? Fact is, people who use libraries typically also own a lot of favorite books -- they just can't afford to buy every book they'd like to read. The parallel to users of P2P networks should be quite obvious, and market studies have proven this.
Unfortunately, it will probably take some time for our laws (and society) to re-balance the ramifications of modern technology. We are currently in the reactionary phase. This follows in line with the history of every major influential / subversive technology.
Now what is worse is that a whole bunch of FOSS supporting firms can be pulled to court with this nonsense.
When large companies sue each other, people shrug and say, "well, that's big business for ya.." When large companies sue small companies, especially for bogus reasons, people turn an ear and many get angry. When large companies sue individuals or mom-and-pop businesses or non-profit groups, you've got yourself a major media frenzy. Right now, this software patent garbage is restrained by the fact that it is only profitable for large companies to sue each other. It isn't worth the bad PR for a large software company to go after small FOSS projects/companies. They have virtually nothing to win monetarily and everything to lose in PR -- which translates to lost revenue.
This could change in the future as the current software giants are obsoleted and resort to increasingly dirty tactics to stay afloat. What this underscores, however, is the vital importance of rapid FOSS development in the next few years. There is a point of no return where even a barrage of lawsuits will be unable to stop the momentum of FOSS. We need to reach that point before the proprietary software giants can effectively respond to their new competitor. And if we can reach this point, it will be trivial to strike down software patents themselves because the masses will be on our side. Irrelevant companies can do little to sway public opinion or policy. Can you imagine the arguments?
Has-been: "We need software patents to insure continued innovation!" USPTO/Courts: "Innovation is happening without software patents.. and in fact, without you last we checked." Has-been: "But we have patent rights on.." USPTO/Courts: "Actually, patent policy is constitutionally bound to promote innovation. There are no inherent rights."
Want to fight software patents? Go out there and innovate. Write free software. Start a small consulting business. Promote FOSS everywhere.
It requires a fair amount of expertise to find and hire a competent software development programmer or consultancy, which is unlikely to be present in a small/medium business whose core business is not software. Will they really be better off hiring programmers to customize OSS rather than integrating off the shelf packages?
Quite often the answer is "yes," especially now that more OSS projects are maturing to the point where required customizations are smaller. Of course, the answer can only be "yes" if you can find someone competent to do the job and help with integration issues. I think this scenario illustrates quite well why a whole lot of geeks need to leave their day jobs doing proprietary crap (many working for far less than they're worth) and become software development consultants. There's a whole lot of need out there and a whole lot of money waiting to be scooped up.
And, of course, there are a lot of other great ways to earn money "doing the Open Source thing." Suppose you want to do full time development and not worry so much about finding large contracts or dealing with integration. One money-making tool most projects have not employed is some form of feature-based reward pool or "feature bounty" if you will. In other words, individuals and/or companies promise to pay a certain amount to give incentive to add a new feature. Once developed, the code is released upon receiving full payment. (there are dozens of variations and ways this could be arranged of course..) If the project gets big enough, you then hire some entry-level developers to provide customer support for a fee while helping with bugfixes. (recent CS grads, etc.. They're a dime a dozen and desperately need real-world experience. You do write clean, understandable code, right?:-)
This is the wrong way to ask about what is a more fundamental issue. You're just begging to get a canned response like "We must continue to evaluate blah blah blah.. balance.. blah blah" because the candidates don't have a clue what software patents are all about. The issue should be explicitly "Do you support copyright and patent reform that many are now calling for?" and the concern should be something along the lines of "Entrepreneurs are increasingly concerned that the current system stifles the ability to innovate because it gives too much power to those with enormous legal war chests and does not put reasonable boundaries on the extent and duration of granted monopoly rights."
However I don't think it would be the most unreasonable thing in the world if Sun demanded if you use their code (rather than, say, Kaffe's) your experimental functionality extensions don't activate unless specifically switched on by the user.
I agree that this method of handling extensions to Java is the "Right Thing" but if Sun was to legally enforce this, the license would not only be GPL incompatible but incompatible with both OSI guidelines and the Debian DFSG (which dictates what is legally free enough for distro..) In other words, Sun must give up more control before the community will be willing to help out. It's really a pretty fair trade-off, because the community is generally a lot better behaved than Sun's proprietary competitors. Most developers would rile against a compatibility-breaking fork of Sun's JVM in the same way they would against an open source browser that made it's own extensions to HTML. There is an unbelieveable amount of professionalism when it comes to Java in the OSS community. A rogue project or two would change nothing, and as prior mentioned, might even come up with a good idea once in awhile.
It's all very well to say that such "experimental project" would "not gain widespread acceptance" but this is simply not the case-- after all, previously one such JVM with incompatible experimental extensions that were on by default shipped with a major operating system.
It's a completely different scenario. Microsoft was trying to change the standard by pushing modifications onto their customers, instead of just offering an alternative for evaluation. In the case of an experimental Open Source fork, it would be the latter. If for some reason an extension gained widespread support, there would more than likely be a reason for this and thus Sun could simply include it in their own official version and specs. Frankly, as a professional developer, I wouldn't use any extension before it was standardized by the JCP or other alternate standards body Sun may choose to promote instead. (No more than I would write software that relies on an experimental hack to GCC.)
This is exactly what Microsoft tried to do with their JVM (and Jscript -- but that's a completely different issue)... If Microsoft had only called it "JavaTwo - The next generation Java flavored environment!" they might have been able to win their law suit with Sun! (Some say there were pattents involved, so that adds some complexity...)
Not quite.. Microsoft's JVM code was proprietary. Therefore, Sun could not pull code from it back into their own. If Sun released their own JVM as GPL, any modifications or forks would be forced into the open. As for patents, they are totally inappropriate for the economics of software development, but Sun seems to be using them, in part, to control Java. (whether or not related patents are bogus or not even in the current screwed-up patent system we have) With the only exception being a specific case of anti-competitive behavior, why should MS not have been allowed to write their own Java-like VM? If software patents factored very strongly in the MS-Sun settlement, then this must be viewed as a setback for software freedom, even if MS "lost." In the same way, I must side with MS over the recent browser plugin lawsuit nonsense. You can't have your cake and eat it too. If software patents are bad, which they are, then Java must stand on its own merit against innovative competitors. If it cannot, c'est la vie. The same goes for.NET..
Sun's problem is that they know that people want to produce non-conformant implementations. They feel they have to stop them doing that. This goal is, by its very nature, incompatible with an open source license. No amount of clever wording is going to change that.
Perhaps this is exactly why Sun has been so reluctant to even approach open source licenses with Java up until now?
Perhaps a better question is this: Why does Sun think that it needs complete control over the Java specification in order to remain a relevant player? It's pretty obvious that this is the real issue. I think they're afraid that Java will be forked into new (maybe better) languages and those languages will detract from the marketshare of Java. Since they don't make any money off the Java language itself, this is a *branding* issue. (Its value is in driving customers towards Sun as a trusted source for hardware and not-for-free software) From a business perspective, the possibility of losing this brand recognition is a valid concern. Nevertheless, it is now an unavoidable threat. There is now plenty of competition to Java, both from MS and from the Open Source world. As great as it is, Java is not the end-all-be-all programming language. (nor is any other language..) IMHO, Sun's best move would be to GPL their Java implementation, strictly enforce the Java trademark based on compliance, and ride out the momentum generated by the Java brand as long as it lasts. (And frankly, this will be quite a long time, given the installed base of mission-critical Java software, where compliance and reliability is king)
So what would happen if an Open Source, non-Java(tm) fork were to make a desireable but incompatible improvement? Simply include it in the next revision of the official Java(tm) spec! There is nothing to say Sun could not pull innovations back out of derivative works for inclusion in the trademark-protected Java specification. This would instantly reduce such forks to experimental projects which, while valuable, would not gain widespread acceptance. In the end, most people would trust that which is certified Java-compliant because most people would prefer stability to the bleeding edge of the language's evolution.
C'mon Sun. We welcome you to become benevolent dictator over a Subversion or Arch tree of GPL'ed Java code. Lets fight our common enemy together. (:
A lot of people say this, but this is not the case in my opinion. If you're talking about the core language, sure. (though some would debate even this..) But in terms of real-world enterprise application development, it is the Open Source community who have made Java successful. The Apache/Jakarta project, JBoss, Hibernate, Spring Framework, etc. Sun-orthodox J2EE doesn't work in the real world, so other Java-based alternatives have popped up to supplement the basic spec and eschew parts of the spec that are flawed. Sun owes its continued existance to Open Source.
MS Office for Linux is not going to happen. Microsoft's power comes through control of the desktop platform. If they ran office on Linux, a lot of people would lose their only reason for sticking with Windows.
I would not say that MSO for Linux will never happen, but I don't think it will happen at any time in the near future. But here's the more important thing that everyone needs to get out of this:
The key to ending this software patent garbage once and for all is ending Microsoft's monopoly. The way to end Microsoft's monopoly is to perfect OOo or else some other Free office suite.
It really is that simple, folks. Microsoft's monopoly must have both Windows and Office to survive. Knock out one leg and the whole cash cow stumbles to the ground. Once Windows loses dominance, the ripple effect will quickly begin to redefine the rest of the software industry. Regardless of alternative platform, users will suddenly have a plethora of free software at their fingertips that they didn't have while using Windows. Many proprietary vendors will go under. The smart ones will adapt and embrace Open Source in various capacities. Not all software will be Open Source (yet), but all commodity software will be. Even if software patents themselves aren't immediately overturned by the courts, their habitat will be destroyed. Will there be lawsuits from the former big players? Of course. Will it be ugly? You can bet on it. But it has to happen sometime. Is it survivable? Two words: public opinion. Remember that we do live in a roughly democratic society.
"The only thing necessary for evil to prevail is for good men to do nothing."
Employee: Dear debian-users@lists.debian.org, the latest package broke our application. Can you fix it? Random Dude 1: Uh, no, but you can. That's the beauty of Open Source. Employee: I don't know how to fix it myself, but the first person to send me a fix gets $500. Random Dude 1: Umm.. wow. OK. I'm on it.
Just because Debian isn't commercial doesn't mean that its developers can't be involved in commerce. There might already be small companies that would offer such on-the-spot support as well.
On the other hand, raw Debian generally shouldn't be used without either sufficient in-house expertise or some form of contracted support.
Eventually the high value add customized software crafting you speak of will only be doable by those with the expertise to do it. Which won't be done in economies that were forced to abandon the technology because it was no longer economically viable.
What you're saying is that over time, very few people in the US will have programming expertise because there won't be any jobs to motivate them to learn. But there are a few pretty obvious reasons why this won't happen:
1.) There are millions in the US who already know how to program. If their skill is needed, it is available.
2.) Of the millions of people in the US with programming expertise, there is a a heavy skew towards the younger generations. By the time these people leave the workforce (30-40 years), we won't even need many human programmers due to advances in software design automation.
3.) It's not very hard to learn how to program. If a need exists, it will be met. Others will learn simply for enjoyment.
4.) A significant number of programming related jobs simply cannot be effectively outsourced. As example, no large organization is going to blindly trust foreign code for their mission-critical applications without at least internal code review. 70-80% of software is written in-house.
5.) Today's programmers will become tomorrow's IT sysadmin staff. This is more of a consolidation of job requirements. Maintaining critical software will be as much part of the job as doing network administration. This will be made possible by increasingly reliable hardware and software, automation, and the next generations of office workers who are more computer savvy.
However in the long run (and linux marketshare will help) manufacturers have to support linux.
Again, fallacious; again, a pipe-dream of the F/OSS community.
Uh.. no, that's just market economics. If Linux becomes the big game in town, everybody will be forced to follow the rules. The question becomes: At what point it makes sense to set down these strict rules? Is Linux popular enough yet that disallowing binary firmwares / driver stubs will actually cost hardware companies in lost sales? Probably not in this particular case. While there are millions of machines running Linux, very few have webcams and even fewer use these budget USB webcams that rely on software image processing routines to work.
On the other hand, I'm pretty certain that Promise was convinced to fully open source their SATA / RAID controller drivers because of pressure from one large customer who wanted to use Linux but didn't want the risk of their binary drivers. It can happen.
Time will tell what the outcome of this will be. No doubt it will get back to Philips and they'll be forced to reconsider their decision one way or another.
There is no monetary advantage to opening source or revealing trade secrets
There is possible monetary advantage of opening source due to increased customers (even if small). But here's the more important thing: there is no monetary disadvantage of opening source. Ever hear of disassemblers? Yeah, the competition uses them. Ever hear of memory probes and signal analyzers? Par for the course. Ever hear of white room reverse-engineering? Yeah, that's pretty popular too. You simply can't hide trade secrets in software. Now *that* is a pipe dream.
Correct. Today's hybrids are crap. Only the most extreme hybrids (45/55mpg) can break even on the cost of replacement NiMH cells every 60k miles or so -- and only if you drive them correctly and are heavy on stop-and-go. Then you consider the upfront cost of a Hybrid vs. used economy car (32/40mpg) and it's no competition. (and don't forget interest since it takes longer to pay off!) You might be able to barely break even over the total life of the car if you get tax credits, are a perfect driver, and don't have maintenance issues with the added complexity..
What we need are all-electric personal commuter vehicles in the $5k price range (so most people can afford both) and high sales taxes on heavy vehicles that make the roads unsafe for everyone. (with exception of large vehicles actually used for their utility, of course)
Some of those jobs created are in different industries or in different sectors of the IT industry that you might not be as familiar with. Sometimes there is a temporary lag as industries restructure, but outsourcing doesn't necessarily change overall employment. It does, of course, change the status quo, and this is what gets people up in arms. Welcome to the capitalist world economy. Look back in history and you'll find hundreds of industrys that were exported abroad to make room for new ones at home. Without fail, the people in those industries think the sky is falling.
It's quite similar to Open Source. Some people will go off on a long tirade about how this movement will put programmers out of jobs one day because most software will be free. Bzzz.. wrong. The jobs will just look a lot different than they do today. As more software is commoditized, there will be more resources available for truly innovative development. That innovation will come from people working out in the real world, solving the needs of their clients or employers -- not folks stuffed into a cubicle farm for 10 hours a day and told to produce what marketing thinks will sell. And ya know what? The more software becomes a process rather than a product -- a service rather than a manufactured good -- the less attractive it will be to outsource primary development. With one possible exception perhaps: US programmers will contract overseas programmers to help develop Open Source code -- most likely to do the boring parts once the design is complete and the foundations are written. And here's the best thing: Those overseas programmers won't be tied to working in slave shops. Once established in their skill, they will be able to work more or less independently in an international job market. Everybody wins.
As a side effect, this will probably also increase code quality and be a huge boost to proper design methodologies. Suppose you're on an IT team in the US, hiring some more-or-less unknown overseas developers as temp help with a project. You'd better be certain that your code is clean, modular, documented, and understandable so that it is easy for others to contribute and so that communication is clear between all parties involved.
Outsourcing and the collapse of the economic bubble is the best thing that ever happened to the IT industry. We're just having some growing pains at the moment.
What is curious is that it is of no benefit to you personally to use BSD instead of GPL for your work. Furthermore, it is of no benefit to other purely open source developers to use BSD instead of GPL for your work. The only folks who benefit from your use of BSD are 3rd party proprietary commercial developers who are looking to free ride on your work.
Honestly, if I spent five years working on something I wouldn't make it public... at least not immediately. Although after a few years, and when there was no big money to be made, I'd release it for free.
In other words, you don't believe that full-time open source development is a viable career. (at least outside of academia)
Real free. Where other people working on their five-year project can look at my code, copy chunks of it, and then sell their program for profit when they're done. I have no problem with that.
In other words, you believe that proprietary software is absolutely necessary and you are willing to help perpetuate proprietary software by giving your work away to other commercial developers. Thus, selectively using BSD allows the "community" of proprietary developers to benefit each other.
In the end this seems to come down to money to you. To me it's about extending human knowledge. There are MANY people who refuse to even look at GPL code (and many are among the most brilliant minds I've ever met).
In other words, you believe that the best way to maximize the extention of human knowledge is through commercial processes. That I agree with. What I do not agree with is the implicit argument that these commercial processes need proprietary code to function (make a profit, thus survive). The brilliant minds you discuss are probably those people in academia right? Two possibilities: 1.) They or their friends might have interest in going proprietary with the results of their research. To them, BSD is great because, while their university holds the copyright, they are not restricted in its future commercial use. 2.) They are old-school types who believe that for their philanthropic research to be of value, it must wind up in commercial products and those commercial products must be proprietary to make money.
For me, does it come down to money? No, it comes down to (someday) eliminating all proprietary software such that all software (knowledge) is freely accessible to all. That is the ideal way for knowledge to be created and spread most efficiently to all mankind. However, the world is currently not run by academics who gladly share their knowledge like good little renaissance scientists. It is run by greed. The only way to free up the knowledge held hostage by greed is to turn that greed upon itself. That is the philosophy behind GPL. Perhaps BSD (or simply public domain) is the ideal. But GPL takes into account the human factor.
Considering that the GPL has never been tested in court, many don't want to be potentially tainted for the rest of their software careers because they looked at GPL code.
People who hold such fears are pretty silly. There is absolutely no legal mechanism in place that would cause people who view GPL code to be tainted. They would have to explicitly copy GPL code into their non-GPL work. It's not like there are trade secrets. Now, by contrast, Sun's unusual SCSL is another matter entirely! (:
So let me just be clear. I have no problem with making money from software. I've made my fair share, but I also believe that giving away software for FREE is not GPL. The GPL is a selfish license, disguised as freedom.
And in my philosophy, the best way to benefit society is for software to be heavily commercialized but not able to be made proprietary in the process. To me, that is a higher degree of freedom.
Do you have examples of a bit more known software?
Poseidon is very well known among developers who use UML. Probably not so many realize it started as an open source project. Other examples? A really significant one is how MS used BSD-licensed Kerberos code for their little "embrace-and-extend" manuever with Active Directory. Could they have written their own Kerberos implementation if that was not an option and they still wanted to be lame by adding proprietary extensions? Sure. But at least they would have had to work a lot harder at it.
Like Apache, for example. There were at least couple commercial Apache versions - Stronghold and something else. There are Oracle version of Apache and IBM's version. So what? What happened with Apache project? Nothing.
Projects like Apache have enormous momentum, a established "brand" if you will, and a very wide audience. They are also the work of hundreds of developers, not a small community. Because of this, they are resistant to proprietary derivatives. Other smaller projects or those with a more narrow audience are far more vulnerable. But even Apache represents a certain risk to the community. Microsoft could embrace and extend it just as easily as they did Kerberos. And guess what? Since the original code is excellent, they'd do a lot of damage to the popularity of Apache by forcing their version down everyone's throat.. (say, by distributing it in place of IIS)
Your arguments do not relate to "real" life. Sorry.
Sorry, they do relate to real life and they will so increasingly in the future as proprietary software companies falter and scramble for options.
Trying to leverage Office into other roles is not going to work. Yes, some people will make use of a web service feature but it will go virtually ignored by all but that tiny fraction that tries out everything new Office paradigm because Microsoft tells them that it's the best thing since sliced bread.
This is probably not so much about adding web services to Office but rather re-defining "word processing" itself. After all, the concept of WP is quite outdated and inefficient given the capability of today's highly networked machines. Traditional WP is not as collaboration-friendly as the underlying technology allows. If this is the case--what MS is actually doing--I have a whole boatload of ideas that I need to put "out in public" as prior art in case MS starts trying to file nonsense patents for what I see as the obvious future of productivity software and document management. Others should do the same. I had these ideas about 5 years ago, though I'm sure others have had similar ideas. I feel that these ideas are pretty darn obvious. MS lawyers would probably think otherwise. Hopefully this beats them to the punch.
As examples:
- Web based forms used to generate / initiate creation of company-standard documents. One person does the layout and style using a WYSIWYG style interface. Everybody else in the company just fills in the form and out pops a perfectly formatted document.
- Optionally, after the form is filled out, it could be automatically grammer/spelling checked and then sent to a revision person/team that filters all outgoing company documents. Or throw in some sort of full-scale workflow system..
- Document creation can have multiple targets. So your form entry might change the company website and also be used to send out a mailing to customers. Again, formatting is automated and workflow tasks are divided appropriately.
- Revision control and document management becomes much simpler and more effective. No more digging through *.doc's saved in a shared folder and then hoping that nobody else edits the document or causes incompatible revisions or deletes revision tags, etc. Searching for documents is quick and efficient because their *content* in a database, not binaries or even flat XML files. Auditing of who actually made which changes to the document becomes possible.
- Backups are finally centralized! No more 300 workstations x local 'My Documents' == Administrator Hell. Sure, you can use some sort of roaming profiles solution, but you still have documents scattered. And not many companies have even implemented RP yet. What was that recent statistic about 80-some percent of important company documents stored on local machines?
- Throw in some easy-to-understand display of document revision with multiple views.. side by side (think WebCVS) or colored tags or translucent overlays or whatever.
- Document exchange between companies or partners can happen without clunky, often insecure email of equally clunky binary document formats. Instead, web services connect the document centers via HTTPS and exchange data cleanly separated into content, definition, and style. In some cases, the other promises of web services come into light.. like business document exchange standards covering purchase orders, contracts, etc. All of this stuff applies to internal use as well, of course.
- What about richer content than HTML forms? My guess is MS would like to extend their browser with some proprietary means to make this possible. To compete, we have the upcoming XForms, but it may or may not be sufficient for all tasks. Maybe java applets will finally have their day of glory?
A lot of this stuff has been done before in different ways. It just needs to be consolidated and appropriate modern technologies implemented.
GPL is about forcing a community to exist, whether it wants to or not.
GPL is like a legally-enforced social contract. In a world currently dominated by abusive use of copyright, it is a way to ensure that people and companies play fairly.
At the end the choice is up to them. And my code lives on to this as a free product...
This is fine if you're talking about trivial software or example code or educational material. But how would you feel if you spent 5 years writing a really great piece of software and then some company took it, added a few things, made it proprietary, and made millions freeloading on your work and not giving a penny back? What if you someday wanted to provide professional services for that software? Oops.. nobody cares about your original software anymore because the commercial fork is so much more polished and has millions of dollars behind it. And worse, nobody in the community really wants to contribute to your code anymore because your commercial "competitor" is only asking $40/copy so it's not worth their time. (And the company can reasonably do this only because they're freeloading and you did half the work for them for free!) It is quite frankly idiotic to write any significant body of code without GPL-style licensing to enable you to at least maintain a strong community around it -- whether individuals or companies. If you're smart, you will find ways to profit as well. Think this doesn't happen in real life? Look at ArgoUML (BSD) vs. Poseidon (proprietary). And there's even a free-beer, limited-functionality version of Poseidon drawing people away from using ArgoUML in *any* capacity!
When you get down to it, it is pretty unreasonable to do any significant amount free software development and not be re-imbursed in some fashion. GPL gives you a lot of future options. BSD is completely giving away the farm.
Now that's freedom.
No, that's anarchy. True freedom includes the assurance of future freedom, because that freedom is seen as a fundamental right. In any anarchy, the strong dominate. In this case, that means large, possibly greedy software companies. With BSD, you are just a puny individual developer with no financial resources. A-squisha squisha..
Until the day when copyright is abolished and proprietary code becomes illegal or at least highly frowned upon by all, GPL is our best hope for true freedom.
ps. bonus points to anyone who caught the HSR reference and knows where it's from. (:
Is there a technical reason for not having a J2EE like environment for python? It seems to me the only reason one does not exist is because the community does not feel like it needs one.
First of all, note that "J2EE" is a random collection of standardized tools that Sun thought would be useful for Enterprise development. It's not an environment. Many tools can more or less stand alone -- you don't have to swallow the whole pill and run a big J2EE app server like JBoss. There's no technical reason why J2EE-like tools cannot be written for Python. In fact, several projects, such as PEAK, have already started to attempt this. The problem is that they are highly immature compared to the existing Open Source Java/J2EE tools (such as those of the Apache project). For better or worse, the community has rallied around Java as the language of choice for building quality enterprise development tools. As a professional developer, Python is really not an option at this point. I need software that works and is well supported by the community. Frankly, the Java software I've used is beautifully written by people who really do know what they're doing -- contrary to Mr. Graham's baseless opinion.
J2EE is insanely complex but I don't think it needs to be that way. Maybe a decent OR layer, a logging API, scheduling, soap server and a servlet hoster is sufficient. All the parts exist they just need to be put together.
J2EE taken as a whole is, in fact, insane -- which is why real Java programmers don't "use J2EE" but rather take the pieces that suit their needs. If you want to see examples of Java "put together" right, check out the Spring Framework and the Hibernate persistance layer. Then read the books by Rod Johnson.
Zope is almost there now.
Zope is improving, but I'm not sure I would label it "almost there" yet. It is still far too focused on web rather than enterprise development. If that's what you need, great. If not, use Java.
Is Closed Source better just because it's harder to *know* when you steal?
First of all, patent infringement is not stealing, so refrain from using that silly, emotionally-loaded misnomer. Secondly, it's hard to *know* about patents regardless, whether the software is open of closed. Most patent infringement occurs accidentally. It's not like copying somebody's elses code -- where you know you didn't write it yourself. If you try to analyze any given piece of open or closed software, it will take you years of professional research to determine whether it bumps into any patents. Having the code doesn't even usually matter because most patents cover tiny aspects or nuances of functionality. This is why software patents themselves are so bogus -- they are all, by definition, trivial. In fact, they're so trivial that it's usually hard to even find them! (hence the term "patent minefield") The state of the art in software is advanced by millions of trivial, evolutionary steps forward. None of those steps deserve monopoly rights.
Open Source is great, but as the licenses make clear, *you* wind up holding all the liabilities. I'm no lawyer, but as far as I know, I don't believe this has ever been tested in court. So don't go spreading those kinds of statements around like they're gospel truth. There are a couple issues: One is a question of where the liability would fall in the case of a legitimate lawsuit. The other is whether software patents would even stand up to serious constitutional scrutiny.
They can certainly sue you to require you to "destroy" your copies of that software.
Probably not. It's different than if some company got caught without adequate copy licenses. At very worst, software in question could be modified to work around alleged infringement.
Slashdot Mirror
First let me say that I think that it is important to provide an emulation option for Windows servers in order to decrease the cost of migration.
That being said-- Linux allows you do to things with your network that you couldn't even dream of doing on Windows.
Yeah, I wasn't discounting the need for emulation as an aid in migration. What concerns me is that too often the focus seems to only be on emulation when there is so much more possible.
I've set up Samba + LDAP to serve Windows clients using Debian. Unfortunately, in this case, it takes a whole lot longer because nobody thus far has seemed interested in writing a good Open Source tool to aid in making this work out of the box and to ongoing Samba administration less of a hastle. Setting up a small enterprise server with Debian feels a whole lot like building a microprocessor given a pile of sand. As a result, we have the market for SLES, RHE, and others. While there's nothing inherently wrong with this, it would be better to have one popular open source solution that everyone is familiar with instead of dozens of proprietary GUI tools packaged with the commercial distros. "Widget frosting" is not a sustainable OSS business model.
A major issue not mentioned in this article is the prevelence of Windows-only server-side software. Besides easier administration using AD, this is another significant reason why people stick with Windows Server in real life. They absolutely need their custom departmental business apps, so the choice of operating system becomes secondary. NOTE: This is why we need a strong focus on real-world F/OSS database applications. This is without question the killer app of Open Source in the enterprise. (Hint: big money here, and think Java)
One last thing not mentioned is the fact that the Windows server environment is not just about sharing files. Group policies, MSI, etc. are powerful tools for administering a Windows network that Samba does not provide. After all, Samba is only one piece of the puzzle. That's not to say that these solutions are ideal, but if you're stuck with a Windows environment, they become a valid factor to consider.
All things considered, we as the Open Source community should not be focusing on emulating Windows Server as the key to the enterprise. This is an endless game of catch up to unstable, proprietary standards. We need to aim higher. We should be innovating and re-thinking the current office computing paradigm. We need to make it attractive not only to replace Windows on the server but also on the desktop as a direct result of the benefits of a purely non-Windows environment. Those benefits can only materialize if we create our *own* enterprise solutions instead of trying to just become compatible with the status quo.
F/OSS software is generally software designed by geeks for use by geeks. I've seen a LOT of great sutff come out of it, but almost always, the person on the other end has been a techie first and foremost and an artist second.
Hah! That's a joke. It takes just as much time to learn Photoshop and Lightwave as it does to learn Gimp and Blender. People sometimes scoff at the new generation of F/OSS graphics software because it's not what they're used to. But I find it just as difficult to use Photoshop after years of using Gimp, so I can understand where they're coming from. The key is educating the next generation on F/OSS tools from the beginning so that we can finally move away from the rip-off proprietary standbys. At the rate that Gimp and Blender are improving, there will soon be no valid technical reason why they cannot be used even for the most professional of tasks. As for the UI side of things, it would be an interesting project to develop an alternative Gimp interface designed for current Photoshop users. It's more about familiar layout than anything. In the grand scheme of things, both free and non-free software needs a lot of work to improve in the HCI area..
Sadly, I fear the ideology might get in the way...
It's a difficult trade-off. If there was a stable way for hardware manufacturers to release binary Linux drivers, there would be a whole lot less incentive to give out specs / driver code among those who are half-hearted about supporting OSS. Sure, we might see almost all hardware supported in Linux, but almost none of the drivers would be open source.
I think the current scenario is the best balance for now. Those who play nice with the community have the least work to do and get the best results (and this also saves them a lot of money). Others who refuse to give out specs or code can still support Linux but there is a penalty for not doing things the proper way. In the past, there have been numerous companies that started out doing the binary-only thing and then realized that it just wasn't worth it and subsequently released the sources.
Ultimately, the answer is patent reform, specifically the formal barring of software patents by the USPTO. (they currently exist only in case law, not formal policy) Legal fears are the only reason why any company would be legitimately concerned about releasing detailed hardware specs or driver code. To date, this has really only significantly affected 3D video chipset manufacturers because of the vicious patenting of every nuance of functionality in this field. As a result, there is an absurd amount of cross-licensing and that involves agreements that cannot be easily worked around.
Does Linux still need a better driver model? Probably. (:
Because: 1.) you might not have actually paid for it otherwise, therefore the seller has lost no revenue. 2.) you might be using it for fair-use purposes, such as research, certain educational use, etc. 3.) you might be sampling it before buying
It's not a black-and-white issue, neither legally nor morally. If 1 through 3 apply, you're probably being dishonest. (as in, not holding up your end of the bargain) In the end, copyright is best seen as an enforced honor system. That is why it is traditionally an area of civil law. (you can sue people who have "broken the contract" and the courts decide if that is really the case) And this is the way it should remain. There are too many grey areas to go around automatically labelling potential copyright-infringers as criminals or "thieves". The only place where these labels clearly belong is applied to commercial counterfeiting operations where there is an explicit diversion of actual revenue from the rightful recipient.
Another way to look at the situation is to compare to a library. If you borrow a book from a library, read it all the way through, and then return it so someone else can do the same, are you 'stealing' from the author? Or what if you buy a book, read it, and then donate it to the library so that others can enjoy it for free? Fact is, people who use libraries typically also own a lot of favorite books -- they just can't afford to buy every book they'd like to read. The parallel to users of P2P networks should be quite obvious, and market studies have proven this.
Unfortunately, it will probably take some time for our laws (and society) to re-balance the ramifications of modern technology. We are currently in the reactionary phase. This follows in line with the history of every major influential / subversive technology.
Now what is worse is that a whole bunch of FOSS supporting firms can be pulled to court with this nonsense.
When large companies sue each other, people shrug and say, "well, that's big business for ya.." When large companies sue small companies, especially for bogus reasons, people turn an ear and many get angry. When large companies sue individuals or mom-and-pop businesses or non-profit groups, you've got yourself a major media frenzy. Right now, this software patent garbage is restrained by the fact that it is only profitable for large companies to sue each other. It isn't worth the bad PR for a large software company to go after small FOSS projects/companies. They have virtually nothing to win monetarily and everything to lose in PR -- which translates to lost revenue.
This could change in the future as the current software giants are obsoleted and resort to increasingly dirty tactics to stay afloat. What this underscores, however, is the vital importance of rapid FOSS development in the next few years. There is a point of no return where even a barrage of lawsuits will be unable to stop the momentum of FOSS. We need to reach that point before the proprietary software giants can effectively respond to their new competitor. And if we can reach this point, it will be trivial to strike down software patents themselves because the masses will be on our side. Irrelevant companies can do little to sway public opinion or policy. Can you imagine the arguments?
Has-been: "We need software patents to insure continued innovation!"
USPTO/Courts: "Innovation is happening without software patents.. and in fact, without you last we checked."
Has-been: "But we have patent rights on.."
USPTO/Courts: "Actually, patent policy is constitutionally bound to promote innovation. There are no inherent rights."
Want to fight software patents? Go out there and innovate. Write free software. Start a small consulting business. Promote FOSS everywhere.
It requires a fair amount of expertise to find and hire a competent software development programmer or consultancy, which is unlikely to be present in a small/medium business whose core business is not software. Will they really be better off hiring programmers to customize OSS rather than integrating off the shelf packages?
:-)
Quite often the answer is "yes," especially now that more OSS projects are maturing to the point where required customizations are smaller. Of course, the answer can only be "yes" if you can find someone competent to do the job and help with integration issues. I think this scenario illustrates quite well why a whole lot of geeks need to leave their day jobs doing proprietary crap (many working for far less than they're worth) and become software development consultants. There's a whole lot of need out there and a whole lot of money waiting to be scooped up.
And, of course, there are a lot of other great ways to earn money "doing the Open Source thing." Suppose you want to do full time development and not worry so much about finding large contracts or dealing with integration. One money-making tool most projects have not employed is some form of feature-based reward pool or "feature bounty" if you will. In other words, individuals and/or companies promise to pay a certain amount to give incentive to add a new feature. Once developed, the code is released upon receiving full payment. (there are dozens of variations and ways this could be arranged of course..) If the project gets big enough, you then hire some entry-level developers to provide customer support for a fee while helping with bugfixes. (recent CS grads, etc.. They're a dime a dozen and desperately need real-world experience. You do write clean, understandable code, right?
This is the wrong way to ask about what is a more fundamental issue. You're just begging to get a canned response like "We must continue to evaluate blah blah blah.. balance.. blah blah" because the candidates don't have a clue what software patents are all about. The issue should be explicitly "Do you support copyright and patent reform that many are now calling for?" and the concern should be something along the lines of "Entrepreneurs are increasingly concerned that the current system stifles the ability to innovate because it gives too much power to those with enormous legal war chests and does not put reasonable boundaries on the extent and duration of granted monopoly rights."
However I don't think it would be the most unreasonable thing in the world if Sun demanded if you use their code (rather than, say, Kaffe's) your experimental functionality extensions don't activate unless specifically switched on by the user.
I agree that this method of handling extensions to Java is the "Right Thing" but if Sun was to legally enforce this, the license would not only be GPL incompatible but incompatible with both OSI guidelines and the Debian DFSG (which dictates what is legally free enough for distro..) In other words, Sun must give up more control before the community will be willing to help out. It's really a pretty fair trade-off, because the community is generally a lot better behaved than Sun's proprietary competitors. Most developers would rile against a compatibility-breaking fork of Sun's JVM in the same way they would against an open source browser that made it's own extensions to HTML. There is an unbelieveable amount of professionalism when it comes to Java in the OSS community. A rogue project or two would change nothing, and as prior mentioned, might even come up with a good idea once in awhile.
It's all very well to say that such "experimental project" would "not gain widespread acceptance" but this is simply not the case-- after all, previously one such JVM with incompatible experimental extensions that were on by default shipped with a major operating system.
It's a completely different scenario. Microsoft was trying to change the standard by pushing modifications onto their customers, instead of just offering an alternative for evaluation. In the case of an experimental Open Source fork, it would be the latter. If for some reason an extension gained widespread support, there would more than likely be a reason for this and thus Sun could simply include it in their own official version and specs. Frankly, as a professional developer, I wouldn't use any extension before it was standardized by the JCP or other alternate standards body Sun may choose to promote instead. (No more than I would write software that relies on an experimental hack to GCC.)
This is exactly what Microsoft tried to do with their JVM (and Jscript -- but that's a completely different issue) ... If Microsoft had only called it "JavaTwo - The next generation Java flavored environment!" they might have been able to win their law suit with Sun! (Some say there were pattents involved, so that adds some complexity...)
.NET..
Not quite.. Microsoft's JVM code was proprietary. Therefore, Sun could not pull code from it back into their own. If Sun released their own JVM as GPL, any modifications or forks would be forced into the open. As for patents, they are totally inappropriate for the economics of software development, but Sun seems to be using them, in part, to control Java. (whether or not related patents are bogus or not even in the current screwed-up patent system we have) With the only exception being a specific case of anti-competitive behavior, why should MS not have been allowed to write their own Java-like VM? If software patents factored very strongly in the MS-Sun settlement, then this must be viewed as a setback for software freedom, even if MS "lost." In the same way, I must side with MS over the recent browser plugin lawsuit nonsense. You can't have your cake and eat it too. If software patents are bad, which they are, then Java must stand on its own merit against innovative competitors. If it cannot, c'est la vie. The same goes for
Sun's problem is that they know that people want to produce non-conformant implementations. They feel they have to stop them doing that. This goal is, by its very nature, incompatible with an open source license. No amount of clever wording is going to change that.
Perhaps this is exactly why Sun has been so reluctant to even approach open source licenses with Java up until now?
Perhaps a better question is this: Why does Sun think that it needs complete control over the Java specification in order to remain a relevant player? It's pretty obvious that this is the real issue. I think they're afraid that Java will be forked into new (maybe better) languages and those languages will detract from the marketshare of Java. Since they don't make any money off the Java language itself, this is a *branding* issue. (Its value is in driving customers towards Sun as a trusted source for hardware and not-for-free software) From a business perspective, the possibility of losing this brand recognition is a valid concern. Nevertheless, it is now an unavoidable threat. There is now plenty of competition to Java, both from MS and from the Open Source world. As great as it is, Java is not the end-all-be-all programming language. (nor is any other language..) IMHO, Sun's best move would be to GPL their Java implementation, strictly enforce the Java trademark based on compliance, and ride out the momentum generated by the Java brand as long as it lasts. (And frankly, this will be quite a long time, given the installed base of mission-critical Java software, where compliance and reliability is king)
So what would happen if an Open Source, non-Java(tm) fork were to make a desireable but incompatible improvement? Simply include it in the next revision of the official Java(tm) spec! There is nothing to say Sun could not pull innovations back out of derivative works for inclusion in the trademark-protected Java specification. This would instantly reduce such forks to experimental projects which, while valuable, would not gain widespread acceptance. In the end, most people would trust that which is certified Java-compliant because most people would prefer stability to the bleeding edge of the language's evolution.
C'mon Sun. We welcome you to become benevolent dictator over a Subversion or Arch tree of GPL'ed Java code. Lets fight our common enemy together. (:
And they've been pretty good stewards of Java.
A lot of people say this, but this is not the case in my opinion. If you're talking about the core language, sure. (though some would debate even this..) But in terms of real-world enterprise application development, it is the Open Source community who have made Java successful. The Apache/Jakarta project, JBoss, Hibernate, Spring Framework, etc. Sun-orthodox J2EE doesn't work in the real world, so other Java-based alternatives have popped up to supplement the basic spec and eschew parts of the spec that are flawed. Sun owes its continued existance to Open Source.
MS Office for Linux is not going to happen. Microsoft's power comes through control of the desktop platform. If they ran office on Linux, a lot of people would lose their only reason for sticking with Windows.
I would not say that MSO for Linux will never happen, but I don't think it will happen at any time in the near future. But here's the more important thing that everyone needs to get out of this:
The key to ending this software patent garbage once and for all is ending Microsoft's monopoly. The way to end Microsoft's monopoly is to perfect OOo or else some other Free office suite.
It really is that simple, folks. Microsoft's monopoly must have both Windows and Office to survive. Knock out one leg and the whole cash cow stumbles to the ground. Once Windows loses dominance, the ripple effect will quickly begin to redefine the rest of the software industry. Regardless of alternative platform, users will suddenly have a plethora of free software at their fingertips that they didn't have while using Windows. Many proprietary vendors will go under. The smart ones will adapt and embrace Open Source in various capacities. Not all software will be Open Source (yet), but all commodity software will be. Even if software patents themselves aren't immediately overturned by the courts, their habitat will be destroyed. Will there be lawsuits from the former big players? Of course. Will it be ugly? You can bet on it. But it has to happen sometime. Is it survivable? Two words: public opinion. Remember that we do live in a roughly democratic society.
"The only thing necessary for evil to prevail is for good men to do nothing."
Amusing, for sure. But there's another approach:
Employee: Dear debian-users@lists.debian.org, the latest package broke our application. Can you fix it?
Random Dude 1: Uh, no, but you can. That's the beauty of Open Source.
Employee: I don't know how to fix it myself, but the first person to send me a fix gets $500.
Random Dude 1: Umm.. wow. OK. I'm on it.
Just because Debian isn't commercial doesn't mean that its developers can't be involved in commerce. There might already be small companies that would offer such on-the-spot support as well.
On the other hand, raw Debian generally shouldn't be used without either sufficient in-house expertise or some form of contracted support.
Eventually the high value add customized software crafting you speak of will only be doable by those with the expertise to do it. Which won't be done in economies that were forced to abandon the technology because it was no longer economically viable.
What you're saying is that over time, very few people in the US will have programming expertise because there won't be any jobs to motivate them to learn. But there are a few pretty obvious reasons why this won't happen:
1.) There are millions in the US who already know how to program. If their skill is needed, it is available.
2.) Of the millions of people in the US with programming expertise, there is a a heavy skew towards the younger generations. By the time these people leave the workforce (30-40 years), we won't even need many human programmers due to advances in software design automation.
3.) It's not very hard to learn how to program. If a need exists, it will be met. Others will learn simply for enjoyment.
4.) A significant number of programming related jobs simply cannot be effectively outsourced. As example, no large organization is going to blindly trust foreign code for their mission-critical applications without at least internal code review. 70-80% of software is written in-house.
5.) Today's programmers will become tomorrow's IT sysadmin staff. This is more of a consolidation of job requirements. Maintaining critical software will be as much part of the job as doing network administration. This will be made possible by increasingly reliable hardware and software, automation, and the next generations of office workers who are more computer savvy.
However in the long run (and linux marketshare will help) manufacturers have to support linux.
Again, fallacious; again, a pipe-dream of the F/OSS community.
Uh.. no, that's just market economics. If Linux becomes the big game in town, everybody will be forced to follow the rules. The question becomes: At what point it makes sense to set down these strict rules? Is Linux popular enough yet that disallowing binary firmwares / driver stubs will actually cost hardware companies in lost sales? Probably not in this particular case. While there are millions of machines running Linux, very few have webcams and even fewer use these budget USB webcams that rely on software image processing routines to work.
On the other hand, I'm pretty certain that Promise was convinced to fully open source their SATA / RAID controller drivers because of pressure from one large customer who wanted to use Linux but didn't want the risk of their binary drivers. It can happen.
Time will tell what the outcome of this will be. No doubt it will get back to Philips and they'll be forced to reconsider their decision one way or another.
There is no monetary advantage to opening source or revealing trade secrets
There is possible monetary advantage of opening source due to increased customers (even if small). But here's the more important thing: there is no monetary disadvantage of opening source. Ever hear of disassemblers? Yeah, the competition uses them. Ever hear of memory probes and signal analyzers? Par for the course. Ever hear of white room reverse-engineering? Yeah, that's pretty popular too. You simply can't hide trade secrets in software. Now *that* is a pipe dream.
Correct. Today's hybrids are crap. Only the most extreme hybrids (45/55mpg) can break even on the cost of replacement NiMH cells every 60k miles or so -- and only if you drive them correctly and are heavy on stop-and-go. Then you consider the upfront cost of a Hybrid vs. used economy car (32/40mpg) and it's no competition. (and don't forget interest since it takes longer to pay off!) You might be able to barely break even over the total life of the car if you get tax credits, are a perfect driver, and don't have maintenance issues with the added complexity..
What we need are all-electric personal commuter vehicles in the $5k price range (so most people can afford both) and high sales taxes on heavy vehicles that make the roads unsafe for everyone. (with exception of large vehicles actually used for their utility, of course)
If outsourcing jobs creates jobs, where are they?
Some of those jobs created are in different industries or in different sectors of the IT industry that you might not be as familiar with. Sometimes there is a temporary lag as industries restructure, but outsourcing doesn't necessarily change overall employment. It does, of course, change the status quo, and this is what gets people up in arms. Welcome to the capitalist world economy. Look back in history and you'll find hundreds of industrys that were exported abroad to make room for new ones at home. Without fail, the people in those industries think the sky is falling.
It's quite similar to Open Source. Some people will go off on a long tirade about how this movement will put programmers out of jobs one day because most software will be free. Bzzz.. wrong. The jobs will just look a lot different than they do today. As more software is commoditized, there will be more resources available for truly innovative development. That innovation will come from people working out in the real world, solving the needs of their clients or employers -- not folks stuffed into a cubicle farm for 10 hours a day and told to produce what marketing thinks will sell. And ya know what? The more software becomes a process rather than a product -- a service rather than a manufactured good -- the less attractive it will be to outsource primary development. With one possible exception perhaps: US programmers will contract overseas programmers to help develop Open Source code -- most likely to do the boring parts once the design is complete and the foundations are written. And here's the best thing: Those overseas programmers won't be tied to working in slave shops. Once established in their skill, they will be able to work more or less independently in an international job market. Everybody wins.
As a side effect, this will probably also increase code quality and be a huge boost to proper design methodologies. Suppose you're on an IT team in the US, hiring some more-or-less unknown overseas developers as temp help with a project. You'd better be certain that your code is clean, modular, documented, and understandable so that it is easy for others to contribute and so that communication is clear between all parties involved.
Outsourcing and the collapse of the economic bubble is the best thing that ever happened to the IT industry. We're just having some growing pains at the moment.
A social contract that I usually want no part of.
What is curious is that it is of no benefit to you personally to use BSD instead of GPL for your work. Furthermore, it is of no benefit to other purely open source developers to use BSD instead of GPL for your work. The only folks who benefit from your use of BSD are 3rd party proprietary commercial developers who are looking to free ride on your work.
Honestly, if I spent five years working on something I wouldn't make it public... at least not immediately. Although after a few years, and when there was no big money to be made, I'd release it for free.
In other words, you don't believe that full-time open source development is a viable career. (at least outside of academia)
Real free. Where other people working on their five-year project can look at my code, copy chunks of it, and then sell their program for profit when they're done. I have no problem with that.
In other words, you believe that proprietary software is absolutely necessary and you are willing to help perpetuate proprietary software by giving your work away to other commercial developers. Thus, selectively using BSD allows the "community" of proprietary developers to benefit each other.
In the end this seems to come down to money to you. To me it's about extending human knowledge. There are MANY people who refuse to even look at GPL code (and many are among the most brilliant minds I've ever met).
In other words, you believe that the best way to maximize the extention of human knowledge is through commercial processes. That I agree with. What I do not agree with is the implicit argument that these commercial processes need proprietary code to function (make a profit, thus survive). The brilliant minds you discuss are probably those people in academia right? Two possibilities: 1.) They or their friends might have interest in going proprietary with the results of their research. To them, BSD is great because, while their university holds the copyright, they are not restricted in its future commercial use. 2.) They are old-school types who believe that for their philanthropic research to be of value, it must wind up in commercial products and those commercial products must be proprietary to make money.
For me, does it come down to money? No, it comes down to (someday) eliminating all proprietary software such that all software (knowledge) is freely accessible to all. That is the ideal way for knowledge to be created and spread most efficiently to all mankind. However, the world is currently not run by academics who gladly share their knowledge like good little renaissance scientists. It is run by greed. The only way to free up the knowledge held hostage by greed is to turn that greed upon itself. That is the philosophy behind GPL. Perhaps BSD (or simply public domain) is the ideal. But GPL takes into account the human factor.
Considering that the GPL has never been tested in court, many don't want to be potentially tainted for the rest of their software careers because they looked at GPL code.
People who hold such fears are pretty silly. There is absolutely no legal mechanism in place that would cause people who view GPL code to be tainted. They would have to explicitly copy GPL code into their non-GPL work. It's not like there are trade secrets. Now, by contrast, Sun's unusual SCSL is another matter entirely! (:
So let me just be clear. I have no problem with making money from software. I've made my fair share, but I also believe that giving away software for FREE is not GPL. The GPL is a selfish license, disguised as freedom.
And in my philosophy, the best way to benefit society is for software to be heavily commercialized but not able to be made proprietary in the process. To me, that is a higher degree of freedom.
Do you have examples of a bit more known software?
Poseidon is very well known among developers who use UML. Probably not so many realize it started as an open source project. Other examples? A really significant one is how MS used BSD-licensed Kerberos code for their little "embrace-and-extend" manuever with Active Directory. Could they have written their own Kerberos implementation if that was not an option and they still wanted to be lame by adding proprietary extensions? Sure. But at least they would have had to work a lot harder at it.
Like Apache, for example. There were at least couple commercial Apache versions - Stronghold and something else. There are Oracle version of Apache and IBM's version. So what? What happened with Apache project? Nothing.
Projects like Apache have enormous momentum, a established "brand" if you will, and a very wide audience. They are also the work of hundreds of developers, not a small community. Because of this, they are resistant to proprietary derivatives. Other smaller projects or those with a more narrow audience are far more vulnerable. But even Apache represents a certain risk to the community. Microsoft could embrace and extend it just as easily as they did Kerberos. And guess what? Since the original code is excellent, they'd do a lot of damage to the popularity of Apache by forcing their version down everyone's throat.. (say, by distributing it in place of IIS)
Your arguments do not relate to "real" life. Sorry.
Sorry, they do relate to real life and they will so increasingly in the future as proprietary software companies falter and scramble for options.
Trying to leverage Office into other roles is not going to work. Yes, some people will make use of a web service feature but it will go virtually ignored by all but that tiny fraction that tries out everything new Office paradigm because Microsoft tells them that it's the best thing since sliced bread.
This is probably not so much about adding web services to Office but rather re-defining "word processing" itself. After all, the concept of WP is quite outdated and inefficient given the capability of today's highly networked machines. Traditional WP is not as collaboration-friendly as the underlying technology allows. If this is the case--what MS is actually doing--I have a whole boatload of ideas that I need to put "out in public" as prior art in case MS starts trying to file nonsense patents for what I see as the obvious future of productivity software and document management. Others should do the same. I had these ideas about 5 years ago, though I'm sure others have had similar ideas. I feel that these ideas are pretty darn obvious. MS lawyers would probably think otherwise. Hopefully this beats them to the punch.
As examples:
- Web based forms used to generate / initiate creation of company-standard documents. One person does the layout and style using a WYSIWYG style interface. Everybody else in the company just fills in the form and out pops a perfectly formatted document.
- Optionally, after the form is filled out, it could be automatically grammer/spelling checked and then sent to a revision person/team that filters all outgoing company documents. Or throw in some sort of full-scale workflow system..
- Document creation can have multiple targets. So your form entry might change the company website and also be used to send out a mailing to customers. Again, formatting is automated and workflow tasks are divided appropriately.
- Revision control and document management becomes much simpler and more effective. No more digging through *.doc's saved in a shared folder and then hoping that nobody else edits the document or causes incompatible revisions or deletes revision tags, etc. Searching for documents is quick and efficient because their *content* in a database, not binaries or even flat XML files. Auditing of who actually made which changes to the document becomes possible.
- Backups are finally centralized! No more 300 workstations x local 'My Documents' == Administrator Hell. Sure, you can use some sort of roaming profiles solution, but you still have documents scattered. And not many companies have even implemented RP yet. What was that recent statistic about 80-some percent of important company documents stored on local machines?
- Throw in some easy-to-understand display of document revision with multiple views.. side by side (think WebCVS) or colored tags or translucent overlays or whatever.
- Document exchange between companies or partners can happen without clunky, often insecure email of equally clunky binary document formats. Instead, web services connect the document centers via HTTPS and exchange data cleanly separated into content, definition, and style. In some cases, the other promises of web services come into light.. like business document exchange standards covering purchase orders, contracts, etc. All of this stuff applies to internal use as well, of course.
- What about richer content than HTML forms? My guess is MS would like to extend their browser with some proprietary means to make this possible. To compete, we have the upcoming XForms, but it may or may not be sufficient for all tasks. Maybe java applets will finally have their day of glory?
A lot of this stuff has been done before in different ways. It just needs to be consolidated and appropriate modern technologies implemented.
GPL is about forcing a community to exist, whether it wants to or not.
GPL is like a legally-enforced social contract. In a world currently dominated by abusive use of copyright, it is a way to ensure that people and companies play fairly.
At the end the choice is up to them. And my code lives on to this as a free product...
This is fine if you're talking about trivial software or example code or educational material. But how would you feel if you spent 5 years writing a really great piece of software and then some company took it, added a few things, made it proprietary, and made millions freeloading on your work and not giving a penny back? What if you someday wanted to provide professional services for that software? Oops.. nobody cares about your original software anymore because the commercial fork is so much more polished and has millions of dollars behind it. And worse, nobody in the community really wants to contribute to your code anymore because your commercial "competitor" is only asking $40/copy so it's not worth their time. (And the company can reasonably do this only because they're freeloading and you did half the work for them for free!) It is quite frankly idiotic to write any significant body of code without GPL-style licensing to enable you to at least maintain a strong community around it -- whether individuals or companies. If you're smart, you will find ways to profit as well. Think this doesn't happen in real life? Look at ArgoUML (BSD) vs. Poseidon (proprietary). And there's even a free-beer, limited-functionality version of Poseidon drawing people away from using ArgoUML in *any* capacity!
When you get down to it, it is pretty unreasonable to do any significant amount free software development and not be re-imbursed in some fashion. GPL gives you a lot of future options. BSD is completely giving away the farm.
Now that's freedom.
No, that's anarchy. True freedom includes the assurance of future freedom, because that freedom is seen as a fundamental right. In any anarchy, the strong dominate. In this case, that means large, possibly greedy software companies. With BSD, you are just a puny individual developer with no financial resources. A-squisha squisha..
Until the day when copyright is abolished and proprietary code becomes illegal or at least highly frowned upon by all, GPL is our best hope for true freedom.
ps. bonus points to anyone who caught the HSR reference and knows where it's from. (:
Is there a technical reason for not having a J2EE like environment for python? It seems to me the only reason one does not exist is because the community does not feel like it needs one.
First of all, note that "J2EE" is a random collection of standardized tools that Sun thought would be useful for Enterprise development. It's not an environment. Many tools can more or less stand alone -- you don't have to swallow the whole pill and run a big J2EE app server like JBoss. There's no technical reason why J2EE-like tools cannot be written for Python. In fact, several projects, such as PEAK, have already started to attempt this. The problem is that they are highly immature compared to the existing Open Source Java/J2EE tools (such as those of the Apache project). For better or worse, the community has rallied around Java as the language of choice for building quality enterprise development tools. As a professional developer, Python is really not an option at this point. I need software that works and is well supported by the community. Frankly, the Java software I've used is beautifully written by people who really do know what they're doing -- contrary to Mr. Graham's baseless opinion.
J2EE is insanely complex but I don't think it needs to be that way. Maybe a decent OR layer, a logging API, scheduling, soap server and a servlet hoster is sufficient. All the parts exist they just need to be put together.
J2EE taken as a whole is, in fact, insane -- which is why real Java programmers don't "use J2EE" but rather take the pieces that suit their needs. If you want to see examples of Java "put together" right, check out the Spring Framework and the Hibernate persistance layer. Then read the books by Rod Johnson.
Zope is almost there now.
Zope is improving, but I'm not sure I would label it "almost there" yet. It is still far too focused on web rather than enterprise development. If that's what you need, great. If not, use Java.
Is Closed Source better just because it's harder to *know* when you steal?
First of all, patent infringement is not stealing, so refrain from using that silly, emotionally-loaded misnomer. Secondly, it's hard to *know* about patents regardless, whether the software is open of closed. Most patent infringement occurs accidentally. It's not like copying somebody's elses code -- where you know you didn't write it yourself. If you try to analyze any given piece of open or closed software, it will take you years of professional research to determine whether it bumps into any patents. Having the code doesn't even usually matter because most patents cover tiny aspects or nuances of functionality. This is why software patents themselves are so bogus -- they are all, by definition, trivial. In fact, they're so trivial that it's usually hard to even find them! (hence the term "patent minefield") The state of the art in software is advanced by millions of trivial, evolutionary steps forward. None of those steps deserve monopoly rights.
Open Source is great, but as the licenses make clear, *you* wind up holding all the liabilities.
I'm no lawyer, but as far as I know, I don't believe this has ever been tested in court. So don't go spreading those kinds of statements around like they're gospel truth. There are a couple issues: One is a question of where the liability would fall in the case of a legitimate lawsuit. The other is whether software patents would even stand up to serious constitutional scrutiny.
They can certainly sue you to require you to "destroy" your copies of that software.
Probably not. It's different than if some company got caught without adequate copy licenses. At very worst, software in question could be modified to work around alleged infringement.