We had a great discussion on Wednesday about where to take Mozpad. Thanks to everyone who attended. Mukunda posted the transcript on his blog.
Some highlights from my perspective: we agreed that Mozpad should be focused on making Mozilla platform products more appealing to developers, but should not itself be a destination site for product information. Instead we should use the appropriate Mozilla websites (particularly MDC). I’d still like to have a nicer-looking Mozpad site to summarize our activities, who is involved, how to get involved, etc. Mukunda said he might be able to help make this happen since my graphical design skills haven’t developed much since fingerpainting in kindergarten.
Further agreement that there isn’t a XULRunner/WebRunner dichotomy. We can work on improving materials for both, and in fact there is considerable overlap (considering that WebRunner is a XULRunner application).
Personally I am planning to finish my API project and shift my focus to documentation, especially high-level descriptions of the products and why they are important. I’m hoping to find time to give some thought to what the XULRunner and WebRunner sections of MDC should look like. One of the various first steps is obviously to coordinate with the relevant documentation people at Mozilla. You know who you are. I’ll be in touch.
Hopefully we’ll see further progress on the outreach website(s) as well (the equivalent of SpreadFirefox but for the platform). Mark Finkle said he would try to get Asa to give us some guidance from his experience with SpreadFirefox.
Finally, we seemed to agree that Komodo was worth looking at in the context of a Mozilla platform IDE since they already have most of what we need. Discussions will continue once we’ve had a chance to take a look.
One year ago today we unveiled the first public beta of AllPeers.
Our primary goal with this first version was to collect the feedback of as many people as possible. Being the most complex Firefox extension in the world combining the best browser and the best P2P protocol, it was essential for us to get real world experience. Our philosophy has always been to release early and often and it has proven to be very useful for our development process. So we listened, hired more people and worked very hard to add features that were requested and address bugs that people found over the seven subsequent beta versions.
In the last 12 months we introduced secure chat, offline storage of files and a bundle with Firefox. We fixed more than 1,000 bugs (from minor enhancement to major rewriting of features). We improved the user interface. We opened the source code. We received the help of fantastic volunteers who translated AllPeers into 15 different languages. We were the recipient of multiple awards and spoke at various conferences. But this is just the beginning and a preview of what we are cooking. We will soon release a new beta version integrating further enhancements and two major new features: the automatic download of files and the support for downloading and most importantly sharing torrents.
It has been an amazing 12 months and it would not have been possible without the dedication of our (small) product team who is now made up of certainly some of the best Mozilla specialists in the world. So to the product team and to the hundreds of thousands of users who are supporting and helping us working toward version 1.0 I would just say one word: Merci !
As I mentioned the other day, I’m grappling with the Mozpad mission, trying to find an encapsulation of our activities that is intuitive, useful and doesn’t overlap with activities that are already well served by other forums. In my previous post I suggested that we might take the platform under our wing and make sure that associated resources (white papers, the SDK, documentation, demos/samples, some sort of IDE, etc.) are accessible to interested parties without excessive trawling.
I had a long chat about this yesterday with Benjamin Smedberg and Mark Finkle (joined later by Robert Kaiser). I would strongly encourage anyone interested in the future of Mozilla, applications and the web to read the chat log. What came out of the discussion is a new hypothesis that all three of us appear to support: the importance of a C++ SDK is diminishing and the value of a platform for deploying web apps on the desktop is growing. I’m very sympathetic to this viewpoint, not least because I spend a lot of time coding in C++ (the verbose Mozilla dialect, that is), and I’m sure I’d be a calmer, happier, better grounded and more fulfilled person with more hair and lower blood pressure if I didn’t.
What this means, concretely, is that the platform to bet on may well be WebRunner. I can’t see any reason why something like WebRunner couldn’t be the basis for most if not all kinds of apps in the future. Naturally there’s a lot of work required to achieve this, not least implementing the relevant items from various people’s XULRunner wishlists to reduce (and ideally eliminate) the need for binary code in Mozilla-based applications and better integrate with the operating system desktop. (By the way, I used to be a proponent of replacing the desktop with the browser interface, but that was before I switched from Windows to Mac.) We need to figure out our strategy for local storage (Google Gears? mozStorage? A combination? Something else entirely?) We need to decide what the fate of XUL is, since the argument that “XUL is for desktop apps and HTML is for web apps” makes less and less sense as the boundary between the two blurs.
Anyway, I probably don’t have to go on about this too much since I made exactly this point in the conclusion of my Future of Applications essay. So alongside the “people-oriented” vs. “product-oriented” discussion, I think Mozpad needs to have a serious discussion about the relative merits of XULRunner and WebRunner and where we should be investing time.
I was encouraged by the feedback (public and private) to my previous Mozpad post. I’d like to have a Mozpad meeting this Wednesday (usual time and place) to drill down on this idea. A few specific things spring to mind:
- Since Mike Shaver suggested they might find room for the SDK builds on the community build hosts, does anyone want to take charge of setting up the build system? This looks like it’s pretty much covered by our Automated Application Packaging Project.
- What about documentation? Mukunda is working on some documentation stuff but said (if I’m not mistaken) that he’s not necessarily comfortable with taking responsibility for the whole XULRunner section on Devmo.
- The Outreach project is huge in the context of a “productized” platform. I feel very strongly that we need to have a name, logo, etc. and do proper branding. Further outreach can wait until we have a first rev of the website set up.
- Speaking of which, it would be super to have someone who could help us make a great looking website. DokuWiki with the default theme was great to get started, but I think we’re ready to take this to the next level. This is a great opportunity for someone who wants to help out but isn’t a developer.
- Nothing about the proposed refinement of our mission affects the platform viability and patches projects, in my opinion. Both continue to be extremely useful to ongoing improvement of the platform.
- As far as the IDE project is concerned, my honest feeling is there is a lot of fragmented work going on that would benefit from consolidation. I understand that this is hard because everyone has their own vision and priorities for the IDE. I’m very interested in talking about the road forward with people who are involved with various aspects of Mozilla IDE development.
If there are other things that people feel will be important to discuss, please let me know.
I’ve seen the iPod Shuffle held up as a quintessential example of Steve Jobs’s “reality distortion field”. Who, after all, would want an MP3 player with a relatively small capacity and no user interface to find a particular track? I would tend to agree that you have to be a pretty happy-go-lucky music listener to be satisfied with choosing a fraction of your music collection and then enduring whatever song happens to pop up at a given moment. Dr Dre comes on just when you’re trying to multiply two five-digit numbers in your head? Dying to listen to that new Celine Dior track you downloaded yesterday? Keep your finger on the Next button and hope for the best.
Be that as it may, for podcasts the Shuffle is brilliant. Hours and hours of audio entertainment fit easily in a sliver of my 2Gb unit. I only have a few podcasts at a time, so stepping through to find the one I want is not particularly onerous. And best of all my Shuffle is beautiful, tiny and has that amazing clip (pure genius) that lets me attach it to my man bag strap or to my pocket-less gym shorts.
One of my favorite jokes is about a couple who visits a counselor after years of marriage, so irked are they that their union is completely perfect in every respect except for one small thing. (Sorry, can’t say more about this since Peer Pressure is a family-friendly blog). Similarly, the Shuffle has one glaring weakness that is all the more annoying because it is otherwise without obvious flaw. Whenever you are listening to something and press the Previous button, it goes to the beginning of the current track. There’s no way to get back to where you are without laboriously fast forwarding while listening intently for the right spot and hoping that your thumb won’t seize up. I seem to do this at least once a day when I go for the Pause button or accidentally brush up against something.
I have two ideas for fixing this. One is to have Previous go to the last track, so Next takes you right back to where you were. Who needs to go to the beginning of a track anyway, whether music or speech? The other is to have a ten-second grace period after hitting Previous, during which Next which take you back to where you were. So if I hit Previous by mistake and find myself transported from minute 56 back to the beginning of my 60 minute podcast, instead of smashing furniture I can quickly hit Next to jump straight back. Perhaps I’m just a weirdo, but I can’t be the only one who’s bothered by this, right?
Based on the great feedback for my last post on this topic (thanks!), it looks like I have broadly two choices to meet my email requirements: Thunderbird with an IMAP server and an extra server-side app to handle full text, or Gmail. I’d like to try the IMAP route first. Apparently the folks who do our system administration were planning to set this up anyway. Since they haven’t made a choice of software yet, they asked if I had any preference. Anyone want to recommend their favorite IMAP implementation? What’s the best software to get Google-like full-text search capabilities?
Apparently my calendar is broken. It says August 24th but obviously it’s April 1st.
Microsoft has dominated the productivity suite market for ages, and they’ve cleverly managed to frame the debate in a way that makes their position almost unassailable. Specifically, every new release has a list of new features, reinforcing the superficially reasonable proposition that more features means better software (and helping to sell countless upgrades that most people debatably didn’t need). I’ve felt for several years that a smart startup could eat their lunch by coming out with a lean-and-mean office suite based on the 80/20 rule.
That’s why I was bemused by the Burton Group report described in this Infoworld article. I’m probably biased because I rarely use a spreadsheet (and never any particularly advanced features) and for text editing I just want a program that will get out of my way and let me write, and then publish the text in an appealing form. I’m also ignorant because I’ve never used Google Apps. Nonetheless, I would at least call into the question the contention that “Google Apps [is] no match for MS Office” because they don’t stack up on a feature-by-feature basis. How about some statistics to let us know what proportion of users actually need apparently indispensable features like endnotes and hiding spreadsheet rows and columns?
Once upon a time I was a markup head, having gotten into the SGML scene just as it was careening towards the mainstream on the back of XML. We always used to make fun of the HTML people and how impure their markup was, although in reality we were insanely jealous of how successful they were. It didn’t occur to me until this February that by hitching my wagon to Mozilla I had long since gone over to the Dark Side, and that the HTML folks who used to be Them were now Us. One particular IRC discussion from last February (which I have edited for readability) was particularly edifying, and not just because it illustrates what happens when you try to simultaneously debate ten really smart people on a topic that they all master better than you. The topic, in case it isn’t obvious, is whether there is any hope of a web consisting of shiny valid XHTML instead of oozing HTML tag swill.
For those who don’t want to wade through the whole chat log, I would sum it up concisely as follows: Microsoft sucks. Somewhat less concisely, the point is that Internet Explorer doesn’t support XHTML, so even people who want to deliver their webpages as compliant XML actually have to send it using the text/html MIME type. This causes the HTML parser to be used, defeating the whole purpose of the exercise, especially the fact that the XML parser (if it were used, which it isn’t) would complain if there were errors in the markup. Not using the XML parser means that the web continues to fill up with documents that computers can’t easily process, preventing the appearance of tons of amazingly cool new applications. Thanks, Microsoft. Did I mention you suck?
Nor can you simply deliver your markup to IE as HTML and to other browsers as XML because of fundamental (albeit subtle) differences between the two languages. There is hope, however, in the form of WHAT WG and (X)HTML 5. Their biggest innovation, from my perspective, is to stop treating HTML as an SGML-based language. (Buy me a beer and I will keep telling you different ways in which SGML is a crazy freak show of an international standard until I pass out or you stop buying me beers.) This means that they can look at how different browsers (none of which include an SGML-compliant parser because that would be like putting a Chernobyl-era fission reactor into every new Prius that comes off the assembly line) actually handle all of HTML’s ambiguous undocumented edge cases, choose the best compromises (read: whatever IE does since Microsoft is the least likely to ever change) and document them.
The best part is that we’ll finally be able to create a single set of webpages and delivery them as HTML or XHTML just by changing the MIME type. This strikes me as ample reason for optimism, despite the gloomy ending of the aforementioned IRC log.
Update: As Boris Zbarsky was quick to point out to me, the WHAT WG’s work doesn’t solve the problems with HTML-to-XML conversion he raised in the chat log. But as explained here it does make it easier for people who are so motivated to use XML tools and data internally and convert to the HTML serialization for the stragglers (including the hilariously labeled “browser that currently holds the majority market share”) who can’t yet handle XHTML.
Coining a term is pretty tough in the Google Age. I mentioned to my friend at lunch that one of the people I follow on Twitter is driving me nuts with their “Twitterhea” (not mentioning any names, mind you), and (when he stopped laughing) he exclaimed that I should blog this funny neologism. I did take the precaution of googling it first, and low-and-behold there are 95 occurrences and twelve distinct hits. The funny thing is that none of them seems to make a big deal out of the fact that they are inventing a new word. It’s so obvious and natural that they just throw it out there like I did in my face-to-face conversation.
Bloggerhea is, of course, a well-known phenomenon.
I’ve been thinking lately about Mozpad and its raison d’être. I can’t seem to shake the feeling that the purpose of the organization is not entirely clear, and that this will turn into a major barrier to achieving something useful. I’m starting to understand why some people (particularly Simon Lucy of Joost, who deserves credit for raising this issue) were pushing to get a clear mission statement formulated.
I originally conceived of Mozpad as a “user group” for people developing on top of Mozilla. But I’m coming around to the view that this doesn’t give it enough to do considering that Mozilla itself is an open source project and has many open forums for developers (something Mike Shaver pointed out). If I want to ask a technical question, I’d rather go to one of the newsgroups or IRC channels where I can reach the broadest possible community of Mozilla core and application developers. And that’s most of what a user group does.
This isn’t to say that we don’t have great and useful action items. But I feel that we would benefit from more clarity of purpose. Specifically, I’m beginning to think that Mozpad should aim to create and distribute a real product. People should be able to go to mozpad.org to get the latest version of the platform and access documentation, demos and other materials (hosted locally or through links to the appropriate mozilla.org). As I’ve made clear, I believe that a truly usable SDK is a must so that people don’t have to go through the fiery crucible of the build system as their very first experience with Mozilla (the software development equivalent of spending a week as a crash test dummy before being allowed to buy a car). I’m also a huge fan of the IDE-in-Eclipse idea. The nice thing is that none of this contradicts our existing action items, it just gives us a better handle on where we are heading.
In fact, I’d like to brand the platform “Mozpad”. It’s a cool name for a platform although it wasn’t conceived as such. There might be some issues with this, however, which I’m looking into.
What do people think of a Mozpad product based on Mozilla, with an SDK, IDE and platform documentation so that it is a viable choice for people who want to develop “rich internet applications” or other multiplatform software? Am I seeing a problem where there isn’t one? Is this far too ambitious? Personally I can’t invest silly amounts of time into this, so if this doesn’t jibe with what other people were hoping to get from Mozpad then it’s not going to fly.
A couple of years ago Cedric and I attended a conference in Zaragoza and took advantage of the trip to spend a weekend in Barcelona. While shopping at El Corte Ingles we stumbled upon a department with tons of cool leather bags in all shapes and sizes. I picked up a small brown leather pouch with a shoulder strap, just big enough for a large paperback (or, I suppose, a small handgun). Cedric got a tiny mini version of the same. I wore my bag religiously over the summer and found it incredibly convenient. I especially liked the fact that I didn’t look like a circus clown with my pockets bulging with wallet, phone, keys and all manner of gadgetry.
Nonetheless, I took a lot of crap from my friends for carrying a “purse”, despite my protestations that “it’s not a purse, it’s European.” A friend’s wife went on and on about my “buzer taška” (literally “fag bag”). In any case, the bag was kind of small and somewhat the worse for wear a year later, and I went to the megamall in Hyannis, Massachusetts while on this summer’s vacation and picked up a bigger, blacker and apparently more masculine version. I still carry it everywhere I go, so I was tickled pink when Cedric sent me a link to this excellent Lifehacker article. Seems I’m not the only red-blooded male who carries a bag everywhere he goes.
Unfortunately I missed the opportunity to send my bag’s contents into Lifehacker, and they’re probably not geeky enough to make the cut anyway. But for what it’s worth:
1. iPod shuffle packed with technology, golf and NPR podcasts (who has time for music?)
2. Headphones
3. Umbrella I put in my bag this morning because it was raining
4. Wallet
5. This week’s Economist
6. 2Gb USB stick
7. Faceplate for my car stereo
8. 2 koruny (about 10 cents) that somehow ended up in the bottom of my bag and which I will gleefully discover some day when I need exactly 2 more koruny to avoid having to break a 5000 koruna note just to buy a stick of gum
9. Car key
10. Meal tickets (yuppie food stamps)
11. Passport
12. Office keys
13. AAA batteries
14. House keys
15. Another car key (for locking gearshift when parked in “high risk areas”)
16. Antique Nokia 6230i to be replaced with my new E90 if Nokia will ever friggin’ sell it to me
17. Car registration
18. Cute little visa booklet that isn’t needed for travel and that I last used when I bought my car and who knows when before that
19. Lint-free cloth for cleaning my glasses
Not shown: gum (forgot it at home), laptop (too huge although the bag has a great padded pouch for when I become a real manager and get a 15″ or smaller), business cards (in my laptop bag but in any case I never seem to have them when I need them.
With the Great Skype Outage heading into its second day with no clear end in sight, pundits like Om Malik are wondering aloud whether the very idea of P2P architectures is flawed:
Folks at Joost, Babelgum and other P2P companies should be concerned about their business prospects going forward. Venture capitalists who have been funding P2P-based services should take this as an early warning on the fragility of the whole P2P ecosystem, where a small glitch can cause widespread problems.
To be fair, Om has since backpedaled on this. (Side note: if an AllPeers rep every says “We love our customers too much to let that happen,” please put them out of their misery.) The actual P2P parts, if correctly implemented, are incredibly robust. By avoiding centralized points of failure, the system can continue running even if large swaths of it go offline. However, some things are much, much easier to implement with a central server. Skype’s registration server, for example, is a centralized service that keeps track of who is registered, what contacts they have, basic profile information and the like (at AllPeers we do the same). I’m not sure how their name resolution works, but you need a way to find out the IP address of a given node (e.g. your buddy Bob) and that’s much easier to accomplish with a server as well.
Basically your network has a P2P part which, for all intents and purposes, can never go down, and a centralized part which is subject to all the same scalability and availability considerations as any pure client/server solution.
So could Skype (or any P2P network) replace its centralized infrastructure with P2P technology that makes downtime a thing of the past? For someone like Skype, who already has a huge and fairly stable P2P overlay network, the answer is probably yes. I would keep the centralized servers but mirror the registration and name resolution data on a Distributed Hash Table. In essence, you figure out which Skype nodes are up most reliably (there must be thousands of people whose Skype uptime is near 100%) and use them to hold a mirror to the data on the servers. The servers would be there to make sure that data isn’t lost if someone goes offline unexpectedly, but otherwise the DHT would be used and no one would even notice if the centralized boxes went down for some time period.
As it transpires, Om’s second article quotes Skype as saying the problem is actually a result of an error in their networking code. The real question is thus whether EBay is an effective steward of what was for a long time a true technical marvel: incredibly reliable, fast, simple and easy to use. Judging from recent Skype releases, I’m not that optimistic.
UPDATE: The New York Times has more details about what caused the outage. If the problem has existed in the software since 2003 then maybe I was a bit harsh on EBay.
I’m in the process of deWindowsification, with a MacBook Pro notebook waiting in the wings to take the place of my tired old Acer. I already have a Mac Pro at home. As part of the switch, I’m looking into changing email clients. Right now I use Thunderbird on my notebook but have a few issues with it:
- I have a several filters and I get an annoying error message fairly frequently when downloading mails. This is particularly irksome when there are a lot of mails to download, since there’s no way I could find to stop the download and regenerate the index, so I have to sit there clicking OK in the dialog box over and over again instead of doing something fun and interesting like watching paint dry.
- I can’t access my email unless I have my notebook with me. I guess this will be less of an issue once I get my Nokia E90.
- Sometimes when I’m traveling the hotel network won’t let me connect to our SMTP server so I can’t send mail.
- No full-text search.
- No fancy features like Gmail’s stars and threads.
I was going to migrate to Gmail, and I found a tool to upload my old mails. But it’s really buggy (it keeps freezing during upload) and the timestamps of all the mails get replaced by the time they are received by Gmail. I uploaded a few thousand mails, which took several days, then got fed up. Other weaknesses of Gmail are the lack of offline capabilities and the annoyingly pointless advertisements plastered all over it.
What I want is to be able to access my mail on both my Macs and my future smartphone. I guess the latter moderates the need for webmail but some sort of web access would still be nice. Offline access on the laptop is definitely a big plus. The kicker is that I’ve been playing with Gmail and the full-text search is really killer. I don’t think I can live without this.
So I’m at a bit of a loss. I still think Gmail+POP would be the best solution if I can find some way to import my old mails. Or do I try to fix my Thunderbird issues (I’m sending this to Planet Mozilla in case this is of interest to the Thunderbird folks)? I guess I can do full text with Thunderbird using Google Desktop, although I didn’t get this to work last time I tried it (admittedly I didn’t try very hard). Or Apple’s Mail application? Would I be able to synchronize between my two Macs? Do I need IMAP? How are other people handling this?
From my perspective, the most interesting thing about the recent leak of Facebook source code is what a non-event it was. As such it’s one of the strongest arguments for open source that I’ve seen in a while.
The leak garnered a lot of attention to a large extent for the same reason that news wires light up nowadays every time that Steve Jobs breaks wind. Facebook is the hype superstar of the moment, so any story involving them is newsworthy. On top of that, a source code leak has the veneer of the illicit, another journalist magnet. But if we take a sober look at the possible negative consequences, none of them appears particularly daunting:
- Security. Someone could analyze the source code and find security leaks, hack into my profile and send my wife those pictures of me in a compromising position with a stripper, a circus clown and a underage tax accountant at my buddy Moose’s bachelor party. (If, of course, I were married and had a friend called Moose.) But these were the same arguments that were made about products like Firefox, and the reality has turned out to be quite different. It’s generally accepted nowadays that the widespread scrutiny made possible by open source yields more secure software.
- Competitive advantage. But surely a competitor will come along and steal all Facebooks good ideas! The truth is that the value of most web applications is more in the community, user experience and backend infrastructure than in the actual source code. User experience can be “reverse engineered” just by using the site. Source code is no help whatsoever in putting in place a scalable server park. And it should be obvious that building a community has everything to do with innovation, timing and network effects and nothing at all to do with specific lines of code.
- Business model. So maybe the source code will help me to strip out ads or otherwise undermine Facebook’s business model? Well, no. The source code that leaked (in PHP) is server-side code that is used to generate client-side code (with healthy dobs of JavaScript). For ad blocking it’s the client-side code that matters, and that’s open source by definition.
- Sloppy code. I might not want my source code to be subjected to public scrutiny if I’m ashamed of it. At the end of the day this is another argument for open source since it forces you to clean up your act. Sloppy code has its price whether or not anyone else ever sees it. In any case, the Facebook code looks pretty enough to me.
To my way of thinking there’s almost no downside to a site like Facebook publishing its source code. The upside is significant, not least the complete elimination of the risk of bogus “stories” like the source code leak attracting the media’s attention.
