Instead, the future is in co-operation and in organizations preserving what is ultimately of value to them, he said.
This is not volunteerism, It is directed self-interest, synchronized self-interest, and there is nothing wrong with self-interest.
My new friend, Jason Gilmore sent me a link to the story. This quote inparticular really struck a nerve with a lot of people I shared it with.
Here is the link to Simmon's presentation at OSBC.
I liked this quote as well:
Three Golden Rules:
OSS is pretty mainstream now, but there is a huge third wave coming. It is going to be tough in the future to be a commercial software company I think.
It isn't just about cost savings. It isn't freeware. It is about innovation, agility, flexibility, and attracting talent.
3 comments:
As the employee of a commercial software company, it's in my self-interest for commercial software to survive. ;) Even beside that, I think commercial software will do just fine. But so will free software. It's not a zero-sum game.
Free software excels for products that do not require huge amounts of R&D. In the common cases this is because either the product is a commodity that is already thouroughly understood or the product has a small, but specialized, feature set. There is tremendous value in those solutions.
Commercial software, on the other hand, excels for products that do require huge amounts of R&D. A great example of this is EDA. (The original one. ;) ) Could a free software project build the UI? Sure; it's not that complex of a UI. Could a free software project build the core logic? I doubt it. The logic requires very smart guys to work very hard for a long time on very hard projects. In general, guys that smart want some shekels for that much hard work.
Collaboration, on the other hand, is the name of the game. Commercial software is not immune from this, a certain Washington-based company notwithstanding. In EDA, all the vendors have to support common file formats in order to compete. This allows their products to interoperate with their competitors'. it's not the company that benefits the most from this, but the user.
The rules are changing for software because the users are becoming more knowledgeable about software. They are learning that software can interoperate, that collaboration is good for them, and that it's in their best interests to drive that process.
Great comment Sarge.
EDA (the original EDA ... Electronic Design Automation) is certainly in a different boat then a lot of other software sectors. I was blown away by the complexity of EDA just seeing demos of some of the products at Mentor Graphics.
I wonder though, could you see some of your customers asking to have access to the source so that they could collaborate with you on its development (perhaps they already do)? Perhaps it would not be a free open source model, but a support option (i.e., get source, can have changes rolled into next version).
Also, I wonder if there is some line that Mentor isn't competitive in (say PCB BlaDeBla for fun) ... could you ever see some General Manager trying to disrupt the PCB BlaDeBla market by open sourcing Mentor's currently inferior, but soon to be superior offering?
Our customers collaborate with us in the form of reporting how they'd like the product to better solve their problems. Unlike other markets, EDA software is very engineering-driven, either our internal engineers or our customers' engineers. I don't think we do as good of a job of getting our engineers together with the customers' engineers as we could, but that's where the new ideas come from.
Management would drop ponies if we opened our source to anyone, even a customer under NDA. The only reason for someone to buy one of our products over a competitor's product is some secret algorithm we have to do a particular task better. Once that got out, it would be a few months before the same algorithm appeared in our competition and we lost our differentiation.
The closest we come to this is providing APIs to the customer. For example, my product provides a Tcl API to the high-level functionality. Customers can write their own Tcl scripts to create custom flows. In the future, we're adding user-customization of the UI as well. But all of that doesn't change the black-box internals, just makes it easier for someone to use the product.
I don't think there would be much improvement to our software by open-sourcing it. It's not that our customers don't have a vested interest in its improvement; it's that improving it takes a lot of work. Certainly there are smart people who could spend the time (and it ain't trivial) to learn the data structures and algorithms well enough to come up with improvements.
It's that I strongly doubt that volunteers would have the hardware and dedication to go through the verification tests that need to be run. It takes dozens of machines (watched by at least one person all the time) hours and hours to do a full run. Maintenance of the build & test mechanism isn't glamorous or much fun so I don't think you could get volunteers to do it. (I certainly wouldn't volunteer for the duty.) Investigating the results of the verification requires communication between lots of different people, which would also be slower and more difficult with volunteers. Of course, in the case of a real failure, the more knowledgeable eyeballs on it, the faster it gets fixed.
To sum, some problems aren't amenable to the open source model: there's a reason why the Linux UI isn't as good as the Mac's.
Post a Comment