There are 4 recognized business models for open source, and 7 business strategies.
The first thing one must recognize is that open source commodotizes a product. So it's intellectual property has no value, and a company must provide some other value-add in order to make money. That turns most software companies' licensing models upside-down, where the license to the IP is the primary sale and the support, documentation, etc are secondary.
Business Models
Give Away the Recipe, Open a Restaurant - This is where you give away the program and charge for install/support/services/training/certification/do cumentation. Due to companies considering the GPL viral, this is the primary way to make money off of GPL code. Example: most Linux retailers.
Loss Leader - You sell the software package (support too) at a much discounted price in the hopes of getting customers to buy your other products. Example: Netscape
Widget Frosting - An adjunct product (that is currently an expense for a primary product, rather than a profit-making product) is open-sourced to improve its quality. Example: SGI + Samba
Clayton Christensen's Conservation of Modularity - You make money at the borders to modular (open source) layers. Example: Sell proprietary software that runs on Linux.
Dual License - Fee for commercial distribution rights and more features
Consulting - Use OSS to provide higher margins at lower prices
Subscription - Provide support for long-term "maintenance" revenue. Example: RedHat (for the most part).
Patronage - Drive standards, enter entrenched markets, commoditize competitors. Example: IBM + Apache vs. MS IIS, IBM + Eclipse vs. Sun & MS.
Hosted - Use OSS to provide a service.
Embedded - Use OSS in an embedded system to save on license costs.
In my research group at a University highly involved with this project, these motes can currently recognize that there is a moving object. They can figure out that it is an object, and can track it. That's about it.
Fooling the sensors into believing that something is moving isn't very difficult. They're light-sensitive so a cloud in front of the sun might trigger it. However, these are somewhat minor problems that will be solved shortly.
The biggest problem is an enemy attempting to confuse the network. However, the network has many safeguards built in with the intention of preventing, detecting, and avoiding any such attacks.
Though I'm not sure how accurate "zapping" the sensors would be, the networks for these dust computers are extraordinarily robust. They are intended to function when most of the sensors are no longer alive.
Also, the networks are very sensitive to detecting false information. There are many safeguards to prevent these kinds of "byzantine attacks". Remember, these are to be used in battlefield situations, so the army isn't going to allow any crafty enemies to disable the motes except physically.
I would say that it would be a long time before "civilian surveillance" of this kind would occur due to technical difficulties.
Currently, the sensors have a difficult time differentiating between an army tank and anything else that is moving. In time, once they have identified an object as a human, the sensors would be confused if you bump into another human, not knowing which one is which. Gathering the detailed information that is necessary to track an individual is many, many years away.
Furthermore, the power for these motes are only intended for a period of short-term activity with long terms of inactivity. Trying to follow around a person with any accuracy would be extraordinarily power expensive.
While it is true that the network does not have "security" as encryption measures, it is secure in a variety of other ways. The attacker of the network would have to be able to find the correct frequency, and figure out the pattern of the message protocol (using AI probably). This alone is quite a task. Then, having to simulate a mote is difficult, because of various verification algorithms that would be employed: these kinds of "byzantine attacks" are discussed in almost every meeting that I have been to when discussing the messaging protocol.
As an aside note, the main power consumer of these motes is not the CPU: the wireless networking consumes 60% of the power alone.
There already is a system out there, albeit closed-source, that provides a better way to type with your eyes than Dasher. The ERICA system allows you to look at a keyboard on the screen, and control the mouse to move and "click" on the letter or word of choice. And I bet that you can get better results with it than with Dasher because it uses a customizable QWERTY layout with buttons for word-completion.
Furthermore, ERICA is integrated with Windows, so you can use it to completely control the computer and do almost anything you need (not sure how well it would work with Quake;-) . And just to make it more interesting, it was made by the same guy that made Stephen Hawking's system!
While it is true that diamonds are a rip-off, they are a VERY sentimental rip-off. What hardDiamond's honey wants and needs is an expensive show of hardDiamond's sentimentality/devotion to her (to show her friends). May I suggest the following:
1) Talk to her again. Find out the 2nd-best thing to a diamond -- an emerald, a 2-week trip to Panama in 5-star hotels, a new car, etc (not pencils) -- something that really is HER that shows YOUR devotion and sentimentality.
2) (Since she already knows your feelings the following won't be a surprise -- she'll probably know where it is going.) Tell her that you simply don't feel comfortable buying a diamond (if she doesn't like it, remember, you are trying to reach a compromise -- and in a marriage almost nothing should be uncompromisable).
3) You and her (mostly her) pick out a cubic zirconia and fixture that will serve the purpose of show-off-ability.
4) Give her your actual sentimental gift, but beyond what she could have expected. You have to pull this off perfectly, or the next step will be quite bitter.
5) Give her ring on bended knee. If she appreciated your other gift, she might feel a bit silly at this point. If she didn't really like it... well, you didn't like diamonds, did you?
6) You yourself act super-poor for a while (so that everybody thinks you went overboard with both a diamond and the other gift).
-- ALTERNATIVE PLAN --
Same as above, but secretly get her a small diamond to be presented in step #5, to show how you are willing to compromise (make sure she realizes that it is not the cubic zirconia that she picked out). If you don't spend too much on step #3 (and she is pissed), she'll forgive you.
I agree with almost everything that Tony Collins writes, and I want to provide an alternative to Linux and Windows and Mac. Something that would run on your generic PCs and is simple enough for my mother to use, but is not as limiting in preferences as Windows, while being open source.
I am looking for like-minded people to join us. The project, Middle Earth OS , is still looking for ideas and opinions as well as people interested in HCI and OSes. You can check out the many different ideas that we have decided to include in the OS in the Forums.
I guess I should clarify. I didn't mean that just 1 VM is running on top of the hardware. It would actually be 2 or 3 (or more) VMs running simultaneously with a native "VM" that is not really virtual but actually the API to the kernel. The VMs would be subject to scheduling (obviously) by the kernel.
Probably the main thing that makes people not consider this idea is that it would be a new OS that does not run any existing programs.
Actually, the purpose behind my proposed idea is for compatibility with existing systems (Linux, Mac, and Windows). Both Java and new.NET programs will compile to a form that is readable by a VM: Java to bytecodes and.NET (C#, VB.NET) to MSIL. And since this system is a few years off, I don't expect too many legacy non-.NET programs to be necessary to run on it. So we would write a JVM and a MSIL VM that would run over this minimal kernel.
Furthermore the OS would have a "VM" that is actually the native API -- so that people could write code that is faster than those requiring an actual VM.
Probably the most difficult part of this aspect of the project would be trying to get Linux compatibility. This would require a VM that interprets compiled Linux binaries and converts them to some form that our OS could use. Do you have any suggestions?
It seems to me that more and more languages nowadays are designed for a VM, thus adding a level in between the OS and the application. Of course, this leads to a slowdown because the JIT has to do its thing AND the compiled code that runs has to use system calls to do what it wants to.
But has anybody given any thought to making a VM that runs almost on top of the hardware with almost no system calls? Perhaps the only interference the OS would make is scheduling and possibly memory management. This kind of approach (like the exokernel approach in the EROS project) would allow a VM to greatly speed up its resultant code because it would have almost direct control of the hardware, and the VM would be optimized for that hardware.
I am working on an OS (Middle Earth OS) that is looking into this kind of design, and would appreciate your input either here or in the project's forums as to whether you think this would work (well) or not.
The first thing one must recognize is that open source commodotizes a product. So it's intellectual property has no value, and a company must provide some other value-add in order to make money. That turns most software companies' licensing models upside-down, where the license to the IP is the primary sale and the support, documentation, etc are secondary.
Business Models
Business Strategies
- Clayton Christensen's Conservation of Modularity - You make money at the borders to modular (open source) layers. Example: Sell proprietary software that runs on Linux.
- Dual License - Fee for commercial distribution rights and more features
- Consulting - Use OSS to provide higher margins at lower prices
- Subscription - Provide support for long-term "maintenance" revenue. Example: RedHat (for the most part).
- Patronage - Drive standards, enter entrenched markets, commoditize competitors. Example: IBM + Apache vs. MS IIS, IBM + Eclipse vs. Sun & MS.
- Hosted - Use OSS to provide a service.
- Embedded - Use OSS in an embedded system to save on license costs.
Good sourceFooling the sensors into believing that something is moving isn't very difficult. They're light-sensitive so a cloud in front of the sun might trigger it. However, these are somewhat minor problems that will be solved shortly.
The biggest problem is an enemy attempting to confuse the network. However, the network has many safeguards built in with the intention of preventing, detecting, and avoiding any such attacks.
Also, the networks are very sensitive to detecting false information. There are many safeguards to prevent these kinds of "byzantine attacks". Remember, these are to be used in battlefield situations, so the army isn't going to allow any crafty enemies to disable the motes except physically.
I would say that it would be a long time before "civilian surveillance" of this kind would occur due to technical difficulties. Currently, the sensors have a difficult time differentiating between an army tank and anything else that is moving. In time, once they have identified an object as a human, the sensors would be confused if you bump into another human, not knowing which one is which. Gathering the detailed information that is necessary to track an individual is many, many years away. Furthermore, the power for these motes are only intended for a period of short-term activity with long terms of inactivity. Trying to follow around a person with any accuracy would be extraordinarily power expensive.
While it is true that the network does not have "security" as encryption measures, it is secure in a variety of other ways. The attacker of the network would have to be able to find the correct frequency, and figure out the pattern of the message protocol (using AI probably). This alone is quite a task. Then, having to simulate a mote is difficult, because of various verification algorithms that would be employed: these kinds of "byzantine attacks" are discussed in almost every meeting that I have been to when discussing the messaging protocol. As an aside note, the main power consumer of these motes is not the CPU: the wireless networking consumes 60% of the power alone.
Furthermore, ERICA is integrated with Windows, so you can use it to completely control the computer and do almost anything you need (not sure how well it would work with Quake ;-) . And just to make it more interesting, it was made by the same guy that made Stephen Hawking's system!
While it is true that diamonds are a rip-off, they are a VERY sentimental rip-off. What hardDiamond's honey wants and needs is an expensive show of hardDiamond's sentimentality/devotion to her (to show her friends). May I suggest the following:
1) Talk to her again. Find out the 2nd-best thing to a diamond -- an emerald, a 2-week trip to Panama in 5-star hotels, a new car, etc (not pencils) -- something that really is HER that shows YOUR devotion and sentimentality.
2) (Since she already knows your feelings the following won't be a surprise -- she'll probably know where it is going.) Tell her that you simply don't feel comfortable buying a diamond (if she doesn't like it, remember, you are trying to reach a compromise -- and in a marriage almost nothing should be uncompromisable).
3) You and her (mostly her) pick out a cubic zirconia and fixture that will serve the purpose of show-off-ability.
4) Give her your actual sentimental gift, but beyond what she could have expected. You have to pull this off perfectly, or the next step will be quite bitter.
5) Give her ring on bended knee. If she appreciated your other gift, she might feel a bit silly at this point. If she didn't really like it... well, you didn't like diamonds, did you?
6) You yourself act super-poor for a while (so that everybody thinks you went overboard with both a diamond and the other gift).
-- ALTERNATIVE PLAN --
Same as above, but secretly get her a small diamond to be presented in step #5, to show how you are willing to compromise (make sure she realizes that it is not the cubic zirconia that she picked out). If you don't spend too much on step #3 (and she is pissed), she'll forgive you.
SF Project Page
Project Forums (feel free to post in the "General Ideas" forum with no login required).
I think that this project has a lot of potential and could provide a viable alternative.
I agree with almost everything that Tony Collins writes, and I want to provide an alternative to Linux and Windows and Mac. Something that would run on your generic PCs and is simple enough for my mother to use, but is not as limiting in preferences as Windows, while being open source. I am looking for like-minded people to join us. The project, Middle Earth OS , is still looking for ideas and opinions as well as people interested in HCI and OSes. You can check out the many different ideas that we have decided to include in the OS in the Forums.
I guess I should clarify. I didn't mean that just 1 VM is running on top of the hardware. It would actually be 2 or 3 (or more) VMs running simultaneously with a native "VM" that is not really virtual but actually the API to the kernel. The VMs would be subject to scheduling (obviously) by the kernel.
Actually, the purpose behind my proposed idea is for compatibility with existing systems (Linux, Mac, and Windows). Both Java and new .NET programs will compile to a form that is readable by a VM: Java to bytecodes and .NET (C#, VB.NET) to MSIL. And since this system is a few years off, I don't expect too many legacy non-.NET programs to be necessary to run on it. So we would write a JVM and a MSIL VM that would run over this minimal kernel.
Furthermore the OS would have a "VM" that is actually the native API -- so that people could write code that is faster than those requiring an actual VM.
Probably the most difficult part of this aspect of the project would be trying to get Linux compatibility. This would require a VM that interprets compiled Linux binaries and converts them to some form that our OS could use. Do you have any suggestions?
It seems to me that more and more languages nowadays are designed for a VM, thus adding a level in between the OS and the application. Of course, this leads to a slowdown because the JIT has to do its thing AND the compiled code that runs has to use system calls to do what it wants to. But has anybody given any thought to making a VM that runs almost on top of the hardware with almost no system calls? Perhaps the only interference the OS would make is scheduling and possibly memory management. This kind of approach (like the exokernel approach in the EROS project) would allow a VM to greatly speed up its resultant code because it would have almost direct control of the hardware, and the VM would be optimized for that hardware. I am working on an OS (Middle Earth OS) that is looking into this kind of design, and would appreciate your input either here or in the project's forums as to whether you think this would work (well) or not.