I am doing less direct development using Mozilla tools lately, but a recent trip to British Columbia has brought home to me, again, why Mozilla is important.
I am doing iPhone development and will, in the future, be doing Android development as well. But I was surprised that, on most of my trip, my iPhone was useless. I often did not have cell service, but when I did, I had no access to network-based services. Apparently I would have had to connect via Rogers and pay roaming charges and I was unwilling to do so. This is the problem with a single point-of-failure in the Internet. This is why we do not have one company, like Apple, running the Internet. Apple is seeking control of the iPhone market for obvious reasons, but this costs us as consumers. We should, as we pay those ever-increasing monthly charges, keep this in mind. Really, the fact that we cannot have data services everywhere is just sad. Companies would rather offer less and control more of it than offer more to consumers if they lose some control. And let's not even talk about how bad the App Store is for finding things. Please. There's to much and it hurts to talk about it.
I am also recently using Chandler for my calendar and for keeping track of 'to do' items. It is an interesting app and I went to see the latest dev versions of it and see about building it. Apparently, I have a level of expectation about open source projects. Apparently it is not worth it to interact with the source unless it builds like Mozilla. Chandler development is Linux-only, and while I could upgrade to the version of Parallels I need (since VirtualBox does not see to do enough for me) and build it that way, I find myself unwilling to do so. Despite my ability to complain about the quirks of building mozilla tools, it seems to work better than most alternatives. But I really only complain loudest about something when I like it. This may not be obvious to people to whom I complain.
It turns out that being connection-less for a time is a good thing, though. It makes you think about the value and cost of being always connected. When I was working for Mozilla, one of the things that was a problem for me (though I did not realize it at the time) is that Mozilla's offices are on-line all the time. It is too easy to be "at the office" every day, all day. Reading most Mozilla posts you see how the veterans deal with it, so that they can keep their families, their friends and their sanity. It probably would have been easier to focus if I had not found the information ecosystem around Mozilla to be so rich and fascinating. One has to balance finding that connection with a new friend in Europe with the need to get things done. It is easier, for now, working for myself, but I will have to figure this out someday. We'll see.
Tuesday, April 07, 2009
Sunday, February 08, 2009
Software Patents and Open-Source
I am slightly sanguine about the possibility that reality and rationality might actually drive the Supreme Court to invalidate software patents, which they might eventually do in the In re Bilski case. I hope the open-source community appreciates the importance of this.
I was working at Apple as they were looking at making a certain technology open source. There was quite a bit of evidence that making this technology available via open-source licenses would make it much more widely usable and it would get maintenance and TLC that Apple had no business case to provide, but it got nixed from higher-ups.
It turns out that one of the best uses of a patented software technology is to seal it in a black box and say nothing. It is a secret landmine that one can use against others. This will not help the software get used, but that is not the point. It does not actually matter whether it is a good patent or not. Lots of bad patents get approved by the Patent Office and the cost of defending against the holder of a bad patent is the same as the cost of defending against the holder of a patent that actually does involve innovation.
Software companies use these patents like playing cards. One big company goes to another and tries to strong-arm some licensing money out of them. The target company pulls out its cards and says, "Sue us for X, Y, and Z and we will sue you for A, B and C." Eventually their lawyers sit down, cards are shown, somebody decides to pay something or not, they write a cross-licensing agreement and both companies go home happy.
A side benefit of this is that small companies that might be developing innovative software cannot afford the ante and they are locked out. The big patent holders, IBM, Apple, Microsoft, Sony at al are happy and they shut down those annoying whipper-snappers who want to do something better.
This state of affairs is particularly saddening when one looks at why we have patents. Ask 100 people "what is the purpose of a patent?" and 99 will say that they protect the author of some discovery or creative work. In reality the temporary monopoly provided to a copyright or patent holder is the means of fulfilling the purpose. It is not the purpose itself. Looking at the Constitution, one sees this power assigned to Congress in Article 1, Section 8 of the US Constitution:
I was working at Apple as they were looking at making a certain technology open source. There was quite a bit of evidence that making this technology available via open-source licenses would make it much more widely usable and it would get maintenance and TLC that Apple had no business case to provide, but it got nixed from higher-ups.
It turns out that one of the best uses of a patented software technology is to seal it in a black box and say nothing. It is a secret landmine that one can use against others. This will not help the software get used, but that is not the point. It does not actually matter whether it is a good patent or not. Lots of bad patents get approved by the Patent Office and the cost of defending against the holder of a bad patent is the same as the cost of defending against the holder of a patent that actually does involve innovation.
Software companies use these patents like playing cards. One big company goes to another and tries to strong-arm some licensing money out of them. The target company pulls out its cards and says, "Sue us for X, Y, and Z and we will sue you for A, B and C." Eventually their lawyers sit down, cards are shown, somebody decides to pay something or not, they write a cross-licensing agreement and both companies go home happy.
A side benefit of this is that small companies that might be developing innovative software cannot afford the ante and they are locked out. The big patent holders, IBM, Apple, Microsoft, Sony at al are happy and they shut down those annoying whipper-snappers who want to do something better.
This state of affairs is particularly saddening when one looks at why we have patents. Ask 100 people "what is the purpose of a patent?" and 99 will say that they protect the author of some discovery or creative work. In reality the temporary monopoly provided to a copyright or patent holder is the means of fulfilling the purpose. It is not the purpose itself. Looking at the Constitution, one sees this power assigned to Congress in Article 1, Section 8 of the US Constitution:
To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries;Does our current system of patents, especially software patents, "promote the progress of science and the useful arts?" The answer is obvious. It does not. Is it obvious enough for the Supreme Court to go against the wishes of the "intellectual property nomenklatura" of this country, with their fictitious billions of dollars on their balance sheets? Maybe. We'll see. Another interesting question is this. On the day after all those patents are invalidated, what will the stock market do? It will be interesting to see....
Sunday, January 25, 2009
Trustedness in Ubiquity and Other Places
I have started to use Ubiquity and it is, of course, as amazing as people have been saying it is. And I see questions being raised about how one gets new commands and how one can trust sources for new commands. I hope that, as these questions get answered, the answers can apply to other areas of concern within Mozilla.
Almost two years ago, I was asking Window Snyder why the add-ons on AMO all had warnings from lack of certificates or authentication. It seemed that MoCo could not decide how to decide whether an add-on is "certifiably safe" or not. Perhaps there is a way to determine whether a command is "certifiably safe" or not. I have a feeling that certifying safety falls in a weird area between what the community around Mozilla can do and what the corporation feels that it should do. When MoCo takes off its nice and fuzzy gloves and puts on its "corporate" hat, what reason do they have for taking on this risk? These kinds of risks are notoriously hard to judge. Or rather, one can see when a problem is less likely to occur, but one can never guarantee there will never be a problem and one can never find a limit to how much damage might be caused. So, there is a clear benefit of moderate import and a slight risk but with no way to guess the cost. A corporation which has to show due diligence will probably not sign up for this risk.
I hope I am wrong. Perhaps this is a way to certify these. And maybe a "casual" certification will work. Sort of like saying, "it is not certified, but this add-on is up on AMO and we like the developer and you should like the developer too but we're not responsible for any problems and yadda, yadda, yadda...", and so on down into the fine print. And maybe this works well enough for everyone, except for dealing with the occasionally nasty security dialog.
But it also seems obvious that the more places one needs trusted content, or trusted sites, or trusted chrome, the more ways there are to stub one's toes. I guess we'll see.
Almost two years ago, I was asking Window Snyder why the add-ons on AMO all had warnings from lack of certificates or authentication. It seemed that MoCo could not decide how to decide whether an add-on is "certifiably safe" or not. Perhaps there is a way to determine whether a command is "certifiably safe" or not. I have a feeling that certifying safety falls in a weird area between what the community around Mozilla can do and what the corporation feels that it should do. When MoCo takes off its nice and fuzzy gloves and puts on its "corporate" hat, what reason do they have for taking on this risk? These kinds of risks are notoriously hard to judge. Or rather, one can see when a problem is less likely to occur, but one can never guarantee there will never be a problem and one can never find a limit to how much damage might be caused. So, there is a clear benefit of moderate import and a slight risk but with no way to guess the cost. A corporation which has to show due diligence will probably not sign up for this risk.
I hope I am wrong. Perhaps this is a way to certify these. And maybe a "casual" certification will work. Sort of like saying, "it is not certified, but this add-on is up on AMO and we like the developer and you should like the developer too but we're not responsible for any problems and yadda, yadda, yadda...", and so on down into the fine print. And maybe this works well enough for everyone, except for dealing with the occasionally nasty security dialog.
But it also seems obvious that the more places one needs trusted content, or trusted sites, or trusted chrome, the more ways there are to stub one's toes. I guess we'll see.
Thursday, January 08, 2009
Amusing iPhone Sound Volume Interface
I waited long enough to be almost the last multicellular organism on the planet that did not have an iPhone. Well, we share our phone plan with my wife's parents and my father-in-law was hot for an iPhone and so here we are.
Some of the interface ideas in it are amazing. Then some are, well, something else.
Everybody has seen the thing where you turn the iPhone on its side and the app that is running rotates. I was looking at the calculator in portrait mode and I was just, literally, seconds away from pointing out I would need some scientific calculator stuff and then turned in sideways and there it is. Very cool.
But the interface for setting the sound volume has a strangeness. For one thing, you do not hear a tone that increases in volume as you increase the volume. You just have to eye-ball the volume indicator. Really. There is no auditory feedback for changing the sound volume. It really boggles the mind.
Then you turn it sideways. The hardware does not change its behavior. So, picture this. In portrait mode you press the down side of the toggle and the sound goes down and a visual "volume progress bar" thing slides to the left. Push on the up toggle, the volume goes up and the "volume progress bar" thing slides to the right. So far, so good. But turn it sideways and you press on what is now the right side of the switch and in my "right-hand-is-right-ish" view, this should make the sound increase. But the volume decreases and the "volume progress bar" slides to the left. And if you press on the left hand side of the toggle, the volume increases and the sound goes up.
I cannot decide if it is my brain that is wrong or, is it possible they just thought it would be ok to respond backwards?
Some of the interface ideas in it are amazing. Then some are, well, something else.
Everybody has seen the thing where you turn the iPhone on its side and the app that is running rotates. I was looking at the calculator in portrait mode and I was just, literally, seconds away from pointing out I would need some scientific calculator stuff and then turned in sideways and there it is. Very cool.
But the interface for setting the sound volume has a strangeness. For one thing, you do not hear a tone that increases in volume as you increase the volume. You just have to eye-ball the volume indicator. Really. There is no auditory feedback for changing the sound volume. It really boggles the mind.
Then you turn it sideways. The hardware does not change its behavior. So, picture this. In portrait mode you press the down side of the toggle and the sound goes down and a visual "volume progress bar" thing slides to the left. Push on the up toggle, the volume goes up and the "volume progress bar" thing slides to the right. So far, so good. But turn it sideways and you press on what is now the right side of the switch and in my "right-hand-is-right-ish" view, this should make the sound increase. But the volume decreases and the "volume progress bar" slides to the left. And if you press on the left hand side of the toggle, the volume increases and the sound goes up.
I cannot decide if it is my brain that is wrong or, is it possible they just thought it would be ok to respond backwards?
Thursday, December 11, 2008
Add-ons Interacting Badly? Nope. report from AddOnCon...
I just wanted to call this out. I am at the Add-On-Con in Mountain View today. The keynote was good. Great questions, good back-and-forth, interesting responses.
I asked the panelists (reps from Conduit, http://www.oneriot.com/, http://www.alexa.com/, http://www.adaptiveblue.com/, http://www.cooliris.com/) how much of their time or mental energy is taken up by dealing with confusions or bugs from cross-addon interactions.
I see this as a, theoretically, very serious problem. It was interesting, though, that the panelists said things like (paraphrasing):
- "browser upgrades are more of an issue. MS is bad about this and Mozilla is much better"
- "this does take up time, but the problems have gotten better"
- "Symantec should not try to clean up people's registry"
- "there are generic best practices and these could be more publicized"
I think the responses I heard speak well of how Mozilla has addressed or is addressing this issue. Considering how huge the problem could (again, theoretically) be, it is great that people who are actually relying on their add-ons to make money do not seem to be very upset or worried about it.
I asked the panelists (reps from Conduit, http://www.oneriot.com/, http://www.alexa.com/, http://www.adaptiveblue.com/, http://www.cooliris.com/) how much of their time or mental energy is taken up by dealing with confusions or bugs from cross-addon interactions.
I see this as a, theoretically, very serious problem. It was interesting, though, that the panelists said things like (paraphrasing):
- "browser upgrades are more of an issue. MS is bad about this and Mozilla is much better"
- "this does take up time, but the problems have gotten better"
- "Symantec should not try to clean up people's registry"
- "there are generic best practices and these could be more publicized"
I think the responses I heard speak well of how Mozilla has addressed or is addressing this issue. Considering how huge the problem could (again, theoretically) be, it is great that people who are actually relying on their add-ons to make money do not seem to be very upset or worried about it.
Sunday, November 09, 2008
Freebase HackDay in SF
It has only a slight connection to Firefox, but I did meet people there doing database-ish things with Firefox extensions to provide a whole experience....
Freebase (http://www.freebase.com) is an odd service. It is a wiki-like database. Anybody can go in, look at a table and decide there needs to be another column on it and add a new column. Anyone can put new data in. Anyone can create new "types" (like tables). There are APIs for managing time information and geo information and all that kind of stuff. They have created the concept of a "Base" which sort of combines a social situation with a custom view of data. It allows a better separation between the model and the view.
The tools are mostly Javascript or Google-app based and they work pretty well.
And how many places can one go to and talk about the re-contextualization of socially-constructed semi-structured database tables into dynamic entities and not have people get glassy-eyed and start looking for open doors or windows to jump out of?
Freebase (http://www.freebase.com) is an odd service. It is a wiki-like database. Anybody can go in, look at a table and decide there needs to be another column on it and add a new column. Anyone can put new data in. Anyone can create new "types" (like tables). There are APIs for managing time information and geo information and all that kind of stuff. They have created the concept of a "Base" which sort of combines a social situation with a custom view of data. It allows a better separation between the model and the view.
The tools are mostly Javascript or Google-app based and they work pretty well.
And how many places can one go to and talk about the re-contextualization of socially-constructed semi-structured database tables into dynamic entities and not have people get glassy-eyed and start looking for open doors or windows to jump out of?
Sunday, June 22, 2008
Mozilla Dev Kit ... and Scratchbox?
Seeing a post on the Mozilla Developer Kit (MozDevKit? MDK?) has gotten me very psyched. I have been trying to add some things to the developer doc site. I see, for example, a lot of really good information in blog posts and then the corresponding DevMo pages are ... not so up-to-date. In general, there is much that can be done to make developing Mozilla more accessible to people and MDC does not get as much love as it deserves from people who are doing development and should therefore be able to write. But they probably have no time to doc because they are, you know, coding. It is a conundrum.
But build environments are complicated. How can setting up such an environment be made easy?
Can a Mozilla development kit can be set up in a trackable, verifiable, chroot-ed environment using a tool such as scratchbox? I have been trying to get a xulrunner (FF Mobile) build working to an embedded device using scratchbox and it has been challenging, to say the least, but interesting. Tools like scratchbox or crosstool seem a very good idea. And every production build environment, such as the one I used while I was in the Dev Tools group at Apple, uses a verifiable, chroot-ed environment. It is really hard to get reproducibility without it, and without reproducibility, it is really hard to help anybody who has problems. This is why most responses to build issues on the newsgroups consist of 'please set up X, Y, and Z, and do A, B and C, and see if that helps....'
Also, the usual use of scratchbox is to build on host A for a different architecture, target B. But A and B can actually be the same. MoCo builds Linux binaries on Linux and Mac OS X binaries on Mac OS X, but that does not have to be so. Of course, scratchbox is very Linux-centric. And I see that a Linux version of the MDK is the first item listed on the aforementioned blog post. This is probably true because Linux is amenable to scripted, verifiable building. But it would be interesting (perhaps for only me) to consider how a scratchbox on Linux could build Mac OS X binaries, or how a scratchbox on Mac OS X could build binaries for either Linux or the Mac. And of course, some might be interested in making Windows development possible, but that is way beyond my bailiwick. Yo no hablo Microsoft and I am just fine with that. Can you imagine, for example, getting the Microsoft development tools into a scratchbox environment? I cannot, and I am sure it would be ugly, but it might be possible.)
Downloading a single file, launching it and then finding oneself in a known, trackable, verifiable virtual host for building Mozilla apps seems a compelling opportunity.
But build environments are complicated. How can setting up such an environment be made easy?
Can a Mozilla development kit can be set up in a trackable, verifiable, chroot-ed environment using a tool such as scratchbox? I have been trying to get a xulrunner (FF Mobile) build working to an embedded device using scratchbox and it has been challenging, to say the least, but interesting. Tools like scratchbox or crosstool seem a very good idea. And every production build environment, such as the one I used while I was in the Dev Tools group at Apple, uses a verifiable, chroot-ed environment. It is really hard to get reproducibility without it, and without reproducibility, it is really hard to help anybody who has problems. This is why most responses to build issues on the newsgroups consist of 'please set up X, Y, and Z, and do A, B and C, and see if that helps....'
Also, the usual use of scratchbox is to build on host A for a different architecture, target B. But A and B can actually be the same. MoCo builds Linux binaries on Linux and Mac OS X binaries on Mac OS X, but that does not have to be so. Of course, scratchbox is very Linux-centric. And I see that a Linux version of the MDK is the first item listed on the aforementioned blog post. This is probably true because Linux is amenable to scripted, verifiable building. But it would be interesting (perhaps for only me) to consider how a scratchbox on Linux could build Mac OS X binaries, or how a scratchbox on Mac OS X could build binaries for either Linux or the Mac. And of course, some might be interested in making Windows development possible, but that is way beyond my bailiwick. Yo no hablo Microsoft and I am just fine with that. Can you imagine, for example, getting the Microsoft development tools into a scratchbox environment? I cannot, and I am sure it would be ugly, but it might be possible.)
Downloading a single file, launching it and then finding oneself in a known, trackable, verifiable virtual host for building Mozilla apps seems a compelling opportunity.
Subscribe to:
Posts (Atom)
