Why come to our job fair?
So Joey's post has you intrigued as to what it means to work for Tucows? Let me add my two cent's worth to explain why I think you'll want to be a part of the team if you've got the right skills, motivation and drive!
The Tucows development team is pushing the envelope in terms of what web services are all about. We're looking for skilled individuals who are willing to take risks, have a vision concerning where the web is heading and don't get all caught up in last year's buzz words… We're looking for the best and brightest to help us develop the internet services of the future. Come to our offices and get a sense of what drives Tucows employees. We're all about innovation and quality offerings. If you feel that that resonates with your interests, we want to talk to you.
Come in to my office and I'll explain why there's a picture of a Technical Academy Award on my wall as well as certificates of recognition from ACM for the multitude of volunteer positions I have held at ACM over the past 20 years. As the current ACM secretary/treasurer, I sit on the ACM executive committee and see where the industry is heading. Working at Tucows puts you in a position to be at the highest level of innovation in terms of defining where the internet should be. That's what we're all about.
If you have ideas related to how the internet could be better and want to be able to implement those in such a way as to touch over 6500 ISP's in over 100 countries, we want to talk to you. Come to our open house on September 30th!
Tucows VP Product Development
Good Ajax Reading
Zimbra's message and collaboration clients represent some of the latest innovations in Ajax web applications, so when they talk about Ajax development on their blog, it's worth reading. Here are some articles that caught my eye.
- OSCON AJAX Slides. Kevin Henrikson's slides from his OSCON 2006 presentation, Ajax Optimization Techniques, in both PowerPoint and PDF formats.
- Ajax impact on server scaling. Some thoughts on the architecture of Ajax as a “husky” client (between “thin” and “fat”, where the network boundary between client- and server-side code is defined by the application programmer).
- Securing Ajax. Some security advantages and considerations for Ajax applications.
- Look Ma, No Mouse. In which they talk about how the Kabuki Ajax toolkit let them add keyboard shortcuts to the Zimbra Collaboration Suite.
Tucows Open House / Job Fair: Saturday, September 30th
On Saturday, September 30th between 10 a.m. and 2 p.m., Tucows will be hosting an open house/job fair. We have a number of job openings for:
- Developers (Junior/Intermediate App Developers, a Senior App Developer and a Contract Web Developer)
- Quality Assurance Analysts (QA Analysts and Senior QA Analysts)
- a Usability Architect
Bring your resume to our offices, located at 96 Mowat Avenue, just east of King and Dufferin. You'll have a chance to meet with Executives & Managers of our Product Development, QA and Usability team, and talk about yourself and the exciting careers here.
Tralliance seeks ICANN permission to introduce Sitefinder 2.0
Tralliance, the good folks that brought you .TRAVEL, are looking to implement something they are calling “search.travel” in the .TRAVEL TLD.
ICANN Opens Public Comment Period on the Tralliance Proposed New Registry Service
– via ICANN.
ICANN's own Security and Stability Advisory Committee, SSAC, is saying that they don’t find any material difference between this proposal and Verisign’s Sitefinder implementation.
Bret Fausett has some thoughts about this on his blog as well.
Poll: Americans don’t want net neutrality (or maybe they don’t know what it is)
I really find the whole Net Neutrality debate somewhat disheartening. There are two sides to this debate, one rooted in the realities of the way the internet works, and one rooted in trying to “optimize” the internet to the advantage of a very specific set of applications (video and voice traffic) offered by a very few providers (primarily large network operators). Unfortunately, one of these sides seems to have gained the rhetorical upper hand and seems to be controlling the current tone and tenor of the discussions.
A nationwide survey of 800 registered voters is being touted by the Senate Committee on Commerce, Science and Transportation because it purports to show that Americans are not interested in net neutrality legislation.
– via Ars Technica
Of course internet users aren’t interested in net neutrality legislation – most internet users don’t have a clue of how the internet works, ought to work and was designed to work.
I personally don’t have an issue with whether or not you want to apply QOS or traffic shaping to your packets, but please, leave mine along. The internet is not a cohesive thing, it is a series of interconnection agreements between various independently operated networks and a series of technical protocols outlining how those interconnects should happen for maximum interoperability. Just because you might own the wires, doesn’t mean that you own the bits.
My biggest problem with the entire situation is that it is largely an artifact of bad regulation. In my opinion, the FCC and CRTC aren’t doing anyone any favors with their 3rd party access and hi-speed internet regulatory policies. Competition between a small number of players with very large market share isn’t competition. Competition between DSL and Cable isn’t competition. True competition can only happen in the absence of over-reaching regulation. Which can’t happen in an environment where the very large players have had the benefit of regulatory protection for far too many years.
The regulators need to get off the pot with this one. We must demand that either strong legislation that protects the internet is enacted, or we must demand that protectionist regulation is dismantled to ensure that everyone has a chance to benefit from the unique opportunities that the internet has to offer.
Getting Involved in CIRA
Mark Jeftovic of EasyDNS makes some great points about the CIRA Board of Directors election currently underway. CIRA is the organization responsible for running the registry and managing the policy for the dotCA ccTLD.
During my 3-year tenure on the CIRA Board, I got the opportunity to travel across the country. Whenever we held a public forum anywhere in Canada, the turnout was usually quite high and the participants informed and enthusiastic.
Then near the end of every open forum I made it a habit to ask the attendees the following question: “How many people here voted in the last election?” and the silence was usually deafening. Less than 10 hands would go up every time, guaranteed.
So why the disconnect between getting live bodies out to an actual event and getting stakeholders to click a few buttons through their web browser?
– via Mark Jeftovic
Historically, a very small number of people were responsible for casting the votes for the candidates that get elected to the CIRA Board – less than 1000 votes were necessary to get elected in past elections. This really needs to change – the bar should be much higher, which means more members need to get involved.
I'm actually a candidate in this election and if you are a CIRA member, I'd really appreciate it if a) you would get involved in this election, and b) support my candidacy by casting a vote in my favor.
I’m going to resist the temptation to turn this blog post into a shameless self-promotion, so if you are interested in my “platform”, you can read more here, here and here. If you have any questions about how to cast a vote or about specific issues raised by my platform, please be sure to drop me a line!
Elliot and Ross Talk About the Kiko Acquisition
Since we launched this blog with the announcement of the Kiko acquisition, it's only fitting that we launch our podcast series with a Kiko-related podcast. This inaugural podcast is of an interview I conducted on Tuesday with Elliot and Ross in which they talk about acquiring a company on eBay while on vacation at the cottage, the so-called bursting of the Web 2.0 bubble, what's going to happen to Kiko's current users, “buy versus build” and the business of online calendars.
We'll post a transcript of this podcast next week.
The podcast is an MP3 file 13.2 MB in size and runs for 25 minutes, 47 seconds. Click here to play it (or right-click and choose “Save as”) to save it to your hard drive.
Elliot Talks about the Kiko Acquisition at TalkCrunch/TechCrunch
Over at TalkCrunch — Mike Arrington's weekly podcast covering “Web 2.0” companies — the most recent post is a podcast interview with Elliot about our recent acquisition of Kiko. The podcast runs for 19 minutes, 35 seconds.
The podcast also gets mention in this TechCrunch article.
Why We Bought Kiko.com
Why Did We Buy Kiko?
While there are a lot of little reasons, I'll cover a few of them in a moment, there is really one big reason why we bought Kiko. We needed the functionality, quite desperately, inside of our email platform and it was going to take us a long time to get it. Especially at the level of sophistication Kiko has.
The Calendar Function
Most webmail platforms have a calendar but very few of them are ever used. It is quite simply a crappy user experience. We as users have a problem with shared calendar inside of Tucows and because we are a mixed-desktop environment we are not able to go with the expensive-frustrating-functional Exchange Server solution. At times there have been real pushes for this internally but I have pushed back and insisted that anything we do with a shared calendar be open standards. There is not much.
We all believe that a calendar is a very important function in the messaging suite for small businesses. Given that people don't want to maintain separate services for personal and business use, and because the line between personal and business services is getting blurrier, we felt this functionality was a big hole for us.
So why didn't we build it? Well the short answer is we have so many things to do in general and so many exciting things to do with email in particular that it was just not going to be possible until at least Q2 of next year and even then the plan didn't really excite anyone around here. It looked sort of like the next-gen of our current offering. Had this not come up we would have probably stayed the course and looked to catch a break. When it did, we quickly went through a simple calculus.
The Important Question
What would we pay to have a kick-ass AJAX-based calendar available now?
When I am dealing with quick, complicated decisions I really like to boil them down to a simple abstract construct. Yes there are a huge number of shadings around that question but at its simplest that is the essence of the decision. What was the value to Tucows of the time and the certainty? Of being in the market with this functionality six to twelve months earlier than otherwise? What was the value of having it be good for sure? Even if we threw it away in six months (not that we plan to do that)?
What I can tell you for certain (and you'll be able to hear more details in an upcoming podcast) is that it was more than we paid!
This Situation and Tucows
From the time the auction was announced, there was great discussion online about the value of Kiko to a buyer and much of it was both accurate and confirming. Justin and Emmett (see them being interviewed by Alan Wilensky here, here, here and here) were absolutely right in determining that Kiko was a feature not a business. We think they were absolutely right in assessing that integration with email was key and that the greatest value here was to someone with a suite of services to integrate with. We felt that this was going to be 2-3 man-years of work and they confirmed that. All of this made us more comfortable in the short period of time that we had to make our decisions.
There were also some interesting facts that were specific to Kiko that made it work for us. It was clear from their posts and such that Justin and Emmett were no longer passionate about the calendar space and were excited to do something else. They felt, and we agree, that this was worth much more with them along for the ride. Probably by a factor of ten. It would have then attracted a completely different type of buyer. We would not have paid that premium for the people. Not that they aren't worth it. Just that our financial calculus was different. This probably kept some of the natural buyers out of the process.
We also did not need a huge base of retail users. They are nice and we will provide them with a great home but if this had been much of a success outside of Mike's 53,651 it probably would have attracted more financial buyers or domainers and the price might have ended up more than we were willing to pay. It is worth noting here (and we also talk more about this in the podcast) that there was clearly interest in the domain name and the traffic. We will certainly monetize that as it is a space we know well, but we also may choose to sell the name off as it is not core for us. Either way it is another place where we, more than most/all other buyers who would be interested in the calendar functionality, will be uniquely able to take advantage of the assets.
In a nutshell, this was the kind of deal where we were buying exactly what they were selling. That makes for good business and, by the way, is too infrequently the case with Internet services.
As we dug deeper there were a number of other little benefits that made this seem like a great fit and got us comfortable pushing ourselves a bit on the spend.
I will call out a few of these, but this list is not exhaustive:
Global User-base – For some the non-US customer set and things like language support may not have been seen as benefits. For us they were a very nice addition. Our business is extremely global with customers in over 110 countries. We have a large European b
usiness and a large South American business. We have plenty of customers in Asia. The customers and languages that come along with Kiko are a nice benefit for us.
Mobile Integration – Kiko has a very impressive set of mobile carriers they integrate with. We were blown away when we dug into this. It will be nice to have that functionality for the calendar. It will be even nicer to have an existence proof for making the rest of our services more mobile. We are just starting to experiment with mobile around the edges of our business and this will help things along.
Nice AJAX Implementation – Kiko is a very nice use of AJAX, especially in a lot of the underlying thinking. To me, that is not about technology, but about making a web app behave more like a desktop app. Learning how this worked within Kiko and having to maintain this code base will be very good for the rest of our services. Again, there is a nice broad application of a benefit to be taken advantage of.
First and foremost this was about better/faster. We were able to get a key feature done well, and done now. In my view we were lucky with a number of the small things that made this happen. The people were not part of the deal which held down value for one group of buyers. The retail user base was real but not too large, which held down value for another group of potential buyers.
There were also a number of side benefits which are important in any good deal. The global user base and language support, the mobile integration and the nice use of AJAX are three examples.
All in, we are quite excited about this, we thank Justin and Emmett for all their hard work, we look forward to giving the existing customers an ever-improving user experience and look forward to bringing a great shared calendar to the millions of end-users and thousands of partners who use Tucows services today.