Author

I am Joannes Vermorel, founder at Lokad. I am also an engineer from the Corps des Mines who initially graduated from the ENS.

I have been passionate about computer science, software matters and data mining for almost two decades. (RSS - ATOM)

Meta

Wednesday
Jul042007

## Selling your mISV (the PeopleWords.com case)

Anthea has just acquired PeopleWords.com. PeopleWords was my first mISV project. My efforts being invested in a more ambitious project (namely lokad.com), I was not able to push PeopleWords any further. Thus, selling was a natural option.

### Auction websites do not work

There are places (ex: eBay, SitePoint) where you can sell websites through auctions. I tried, and in the end, it was pure waste of time. Basically, those auction websites are overwhelmed by people trying to sell turnkey websites (ex: web forums about some random topic). As a result, the only thing that comes into the price equation is your traffic; no matter if your website is driving Venture Capitalists or Paris Hilton fans. Unless, you are trying to sell some social networking web application, I would really suggest NOT to go for auction websites.

### Contacting the right people might have work

Making direct proposals to the "right" people to buy your business might be a good option, especially if you are doing B2B. For PeopleWords, the task was looking time consuming (there are too many big translation agencies out there). Thus, I did not even tried that one. Although, I think this approach could have been effective nonetheless (but I can't tell for sure).

### Putting a "For Sale" sign on your website does work

I have been hesitating one month about putting a "For Sale" sign on the front page of PeopleWords. I was wrong to hesitate, the sign proved to be very effective. I was wondering if the sign could negatively impact the business that I was precisely trying to sale. It turned out that the sign had no tangible effect on the business operations. Yet, within a few weeks, I had received half-a-dozen of offers from people that seemed to be genuinely interested.

### You do not sell a mISV, you sell a business plan

Being the sole author of PeopleWords, the main concern of the potential buyers was to know whether PeopleWords had any value without its founder (i.e. myself). At this point, I was no more selling a website, but I was selling a business plan tailored to the profile of the potential buyer. Basically, two points that had to be detailed were: PeopleWords can be maintained and extended without me - PeopleWords can leveraged through the buyer business (and vice-versa).

Thursday
May312007

## Buyer's guide to development outsourcing

Outsourcing parts of your IT developments can be highly cost effective. While running Lokad.com, I have outsourced most of the work for 3rd party connectors (23 of them at the time) and I am considering the outcome as more than satisfying since I would never have achieved the same amount of work without outsourcing, considering comparable delays and financial investments.

This document is a small guide for mISV or ISV that might be willing to go freelance too. May this document help you to avoid my early mistakes.

### Getting freelance proposals

Finding freelancers is easy, but being a good freelance manager is hard. Indeed, you have plenty of open freelance websites. I have been using Guru.com and GetACoder.com (among others), but I think that the freelance website has a very limited impact on the outcome of your outsourced projects. Just stick to freelance websites with significant traffic and it should be OK. Do not ever accept to pay anything upfront to post your job, you would be wasting your money.

Multi-posting is cheap, I suggest not to hesitate to cross-post your job descriptions. It requires a bit more work to keep track of all your postings but it increases the amount of proposals that you get. Since you are going to navigate within tons of websites, proposals, coder profiles, I suggest to create some bookmark repository to manage the whole process: a non-public wiki page is perfect for that especially, if you work in a team. Having 100 proposals is not an issue, you just need the right sorting algorithm (see next section).

Disclose your name and your company. Usually the freelancer gets paid at the end of the job. Thus, the freelancer is taking the risk of not getting paid. By disclosing your name and your company, you are reducing risk, in the opinion of the freelancer, of not getting paid. Anonymous job posting are just more suspicious; and the freelancers are going to charge you more based on that suspicion.

The job must be factual and non-ambiguous. Writing a good job description is hard, especially if you want it done quickly. The first paragraph should be a Job overview. In 5 lines or less the freelancer must know whether this job match his technical skills. It's really important to list all the technologies, languages and tools in this section. If that list can't fit into 5 lines, then you should consider splitting this job into smaller ones. The comes the Delivery section. This section is the exhaustive list of all the documents that you expect to be delivered by the freelancer and the end of the job. Do not forget to specify the formats and possibly the encoding. At the end, the extensive description and your requirements should be found. Notice that this order is respecting the inverted pyramid principle.

Make the job as much stand-alone as possible. Taking over a job can be a significant investment for a freelancer if he has to get familiar with your tools, your own software libraries (worse, your home-made programming language). The freelancer is going to charge you for this take-over investment. Thus, if you want to save money, make the job as much stand-alone as possible. Often it means that you ill handle yourself the integration of the delivered code into your systems.

Go for small jobs (no more than $1000 at once). The larger the job, the more uncertainties; thus it's better to stick to small jobs. First, freelancers are only paid at delivery, thus they will not accept to commit themselves to bigger jobs without being paid upfront. Then, if it's safer on your end to be able to make adjustments along the way like changing of freelancer (if the one you picked does not match your requirements) and/or adjusting your requirements. Suggest reasonable price and delay. Although, it might be a bit counter intuitive, suggesting a reasonable price is actually a good way to lower the final price. First, it sends a signal to the freelancer about the scope of your job. The worse situation for a freelancer are the ill-defined requirements that leave a large latitude in the workload estimation. By helping the freelancer to make his workload estimation, you are decreasing the job uncertainty and thus, the price associated to this uncertainty. A question at the end of your job description. This question should be factual and related to the job itself. The purpose of this question is to facilitate your choice when you will be sorting out the dozens of proposals that you did get for the job. Basically, you can discard all the proposals that do not start by addressing your final question. Indeed, if those freelancers did not even bother to read your job description until the end, trusting the job in their hand is a bad idea anyway. ### Choosing the right freelancer Do not trust ratings for IT projects. Many freelance jobs are actually home works submitted by US students. Since 1st year college home works do require much skill (think of Hello World style exercises), many poorly skilled freelancers ends up with tons of positive ratings. Also, non-technical people submit loads of trivial IT jobs like converting CSV data into Excel data. I mean "trivial" for IT professionals, not for your Uncle, the divorce lawyer, who is also buying IT services occasionally. At the end, I have found that positive ratings aren't reliable for coders. Discard cut and paste proposals. A lot of Indian companies (well, not only India in fact, they just tend to be more visible) are just cut-and-pasting generic proposals. Those companies do do not even bother to read your job description, and automatically propose a random amount for your job (typically$2000). They also tend to send you a private message (cut-and-pasted as well). Spotting those proposals is easy. Do not even bother to read their long stories about the 1000 satisfied customers. Choosing such a company is only asking for trouble. To be discarded at first sight.

Go for specialists. A lot of freelancers go for the "Jack of all trade" strategy and submit proposals at random no matter the technology (PHP, Java, C#, C++, ...). In my experience, the best freelancers are those who are heavily specialized in a few areas; even better but it's rare, the freelancer who's an expert with a list of applications (like Oracle 5 to 10). The cost of outsourcing is highly dependent of the final productivity of the selected freelancer. More specialization means shorter delays and increased code quality.

The country has no importance. The "right" person can be anywhere, including the "expensive" countries. As stated previously, the price depends heavily on the final productivity of the selected freelancer. In my experience, productivity easily varies of one order of magnitude between specialized and non-specialized developers. Skills matter, countries do not as long as people are fluent in English.

Go for independent freelancers. Outsourcing companies just complicate the process without adding value. The company is just another communication layer: you get a "manager" between you and the "coder". If the requirements need to be adjusted along the way (it happens often for the fine-grained detail of the job), you have to negotiate with a manager who do not really understand the problem, because he is not in charge of the job and then re-forward the decisions to the coder. Worse, all the good freelancers realize quickly that an outsourcing company on top of their head is not adding value but eating a significant part of their lunch. As a result, the best freelancers are always those who work for themselves. Do not get fooled by pretty websites of outsourcing companies. At the end, the only thing that matters is the skill of the person working for you.

Probe freelancer responsiveness. Once you've cornered a small set of interesting offers, I suggest to probe the "responsiveness" of those freelancers. Most freelance websites provide some sort of private message system. Just a send a private message (raising a question about the freelancer proposal for example) to see if you get an answer within a short delay. In my experience, discard any freelancer who can't respond to your message within 24h. Responsiveness is a key of effective freelance works, if you can't even get an simple answer like "I am too busy right now, give me 48h", then the chance to get the job done are low.

### Managing the freelancers

Outsourcing must be part of your strategy. Managing freelancers take time and skills. Taking the "right" strategic decision can significantly simplify your outsourcing processes. For example, at Lokad, we have put released all our 3rd party integration components as open source. Disclosing this source code is not an issue since it does not impact the Lokad core business. Yet, in terms of outsourcing, it significantly simplifies the process. We do not need to transmit any access codes to freelancers, everything being readily available. Furthermore, it facilitates price and delay estimation on the freelancer side. Open source is only one option among others; but keep the idea in mind: a lot can be done to facilitate 3rd party developments without damaging your core business.

Anticipate a high failure rate. A lot of things can go wrong. You might realize that the freelancer do not have the required skills. The freelancer is bidding on many jobs at once and takes other commitments after bidding on your job. Your job description was ambiguous. etc... Anticipating a 30% failure rate while hiring a "new" freelancer is not unrealistic. Yet, a 99% reliability would cost you x10 more; thus it's a trade-off between acceptable risks and costs. Part of the reasons that make outsourcing cheap is because nobody takes strong commitments.

The infrastructure has to be ready. There are tons of tools that facilitate remote freelance works: source code manager, bug and feature tracker, open forums, etc... This infrastructure has to be ready before you actually start to look for freelancers. Otherwise, you and your freelancers will end-up wasting a lot of time on mundane communication details.

Strong IT skills are required. You must be able to do what you are asking from the freelancer; at least potentially, if the time was given to you. First, if you're not an expert yourself, you will not be able to write an "efficient" job description that include the necessary technical details. Second, the freelancer is going to raise very technical questions on the job (like "What encoding do you want?"), if you are not able to answer, then the whole process is in trouble because even the smartest freelancer does not know the exact technical requirements of

Be super responsive. Remember that most of the time, when the freelancer is raising a question, it's because he is stuck. In order to move forward, he needs your answer NOW. Making yourself available through your favorite Instant Messenger can greatly increase the speed of your freelancer. Worse, if you're slow to answer, the freelancer might be tempted to start another job because, you're not keeping him busy (wasted time = wasted money) and this is not going to improve anything for your deadlines.

Nights and week-ends do not count. Most of people in the world do not live in the same timezone as you do. Thus, your "business hours" are completely irrelevant when it comes to freelancing. Also, many freelancers do have a part-time or full-time jobs already and wants to make some extra money during the week-end. In my experience, those people tends to be among the most skilled and efficient freelancers. Yet, those people are working the weed-ends. The "super responsive" condition applies 16h / day and during week-ends too.

Source code must be proof-read. Never trust delivered code without proofreading it. Proofreading takes time, but not doing it is asking for trouble because the freelancer will not be there to answer your questions once the job is closed. First, you must make sure you understand the delivered code entirely (see point below); but you want also to make sure that your coding guidelines are respected and that all the job requirements are met.

Ask for code comments, re-ask for code comments. Once the job is closed, the freelancer is gone; leaving you alone with the delivered source code. As a result, the source code must be heavily commented in order to be sure that the code can be maintained at a reasonable cost. Yet, the code comments somehow conflict with the freelancer goal get it done as fast as possible and move on. Thus, you have often to put some (limited) pressure to get source code comments from freelancers.

A formal testing process has to be devised. If unit testing is possible in the context of your job, then go for unit testing. Otherwise, make sure you that you have a formal way of to validate the delivered source code. If the validation/testing process is manual and tedious, you can include it as a part of the job description. For example, I have often asked the freelancers to provide all the necessary screenshots as a part of deliverable elements.

Once the job is done, pay immediately. Depending on your business, several weeks of delay for a payment might be acceptable. Yet, for online jobs, several weeks is a HUGE delay. As a rule of thumb, freelancers expect to be paid in less than a week. In this respect, instant payment systems (like Paypal) are usually quite appreciated by freelancers (at least for those who have access to Paypal in their country). Being a fast payer is important for the freelancer, delaying the payment for weeks will significantly reduce your chance to get this freelancer working for you again; especially if the freelancer is talented.

Thursday
May242007

## Spam 2.0 or the spammers reloaded

Spammers are legions, and unfortunately, most recent systems are just very weak against adversarial behavior (see my previous discussion on the Google case ).

In the last few months, I have just noticed no less than 4 new kinds of spammers.

• P2P spam targeting file-sharing applications such as Emule. The basic idea is the following: spread, through the P2P application, a virus that breaks into the P2P application itself. Once the P2P application is infested, all the incoming requests will return the virus wrapped under the name of the incoming query. For example if the incoming request is "some illegal song" then, the infested P2P application will claim the file "some-illegal-song.mp3.exe". Nasty but effective.

• SMS spam with incentive for the recipients to call a very expensive phone number. Indeed, sending SMS is not free (as far I know); thus you need a strong incentive like "To the owner of 0123456789, you've won a Nitendo Wii, call 987654321 to claim your prize". No need to tell that 987654321 is anything but a tool-free number.

• Instant Messaging spam targeting applications such a Skype. Actually, I would suspect that some black hat guys managed to pass through the "usual" white-listing systems because I end up, once or twice a day, forcefully connected into huge conference calls (with roughly of 200 people); the spam being sent through the conference canal.

• Virtual Worlds spam targeting popular MMPORGs such as World of Warcraft. Basically, spammers just start flooding the main discussion canals with commercial links. So far, it was mostly Warcraft-related (like buying Warcraft gold coins with US Dollars), but I suspect that pretty soon, spammers will realize that they are able to sell fake drugs and fake watches on Warcraft too.

Spam has already upgraded toward the version 2.0 but I am still waiting the delayed release of Cypercop 2.0.

Wednesday
May232007

## Get your TCO assessments right - fight the urge for home-cooking

TCO stands for "Total Cost of Ownership". The concept has been known for decades, yet when it comes to software, even IT professionals have real difficulties to make correct TCO estimations. It's true that software TCO is a difficult task: first, it's really hard to compare products especially if the products involve hundred of features as it is usually the case, second, TCO heavily depends on the way you are actually using the product, MS Excel has an excellent TCO if you want to make some personal budgeting operations, but the TCO would be abysmal if you would try to use MS Excel as an accounting system for your mid-size company.

An issue that I have often encountered in software companies is, what I would call, the urge forhome-cooking; home-cooking always taste best, no matter the actual skill of the cook, but you can't really criticize a relative. Unfortunately, home-cooking usually costs way more than industrial food as soon as you stop considering that the cooker time is just free.

Is your IT company a victim of the home-cooking syndrome?

Typical symptoms include
- Hey, let's recycle this old PC into a server. Unfortunately, the machine resources are too low for Windows;
thus, you switch to Linux. Then, you start having hardware issues; after all, it's an old PC, what did you expect. At the end, you spend 4h/week just taking care of the old PC. TCO = more than 800 EUR a month, probably twice the price of a new PC.
- We have an home-grown FOO solution. Replace FOO by keywords like compiler, programming language, accounting, time-tracking, billing-tracking, email management, CRM. All sort of things where cheap on-the-self software solutions exist anyway. Software companies are really weak against this because it's fun to start a new project but the costs are just terrible.
- We need to hire someone to manage our systems. In software companies, practically anyone has the skill to manage applications, plus the market cover 200% of the needs for software companies. If you start needing full-time people dedicated to your IT
infrastructure in your less-than-20-people-mISV, then something is wrong.

In order to reduce the IT infrastructure TCO, the most efficient solution that I have found so far consist in migrating to hosted & managed solutions whenever possible. For example, instead of building your own Subversion server (cost = 10h at setup + 2h / per week for maintenance) just go for hosted-projects.com (cost = 10 EUR per month or so). More to come on the subject, stay tuned...

Sunday
Feb042007

## WetPaint is far too expensive, migrate or die

WetPaint is a hosted wiki solution. Although Wetpaint still lacks from "professional" wiki features like being able to insert custom HTML or scripts, it's a nice, simple wiki application with a great look&feel. I have triedWetPaint, I did even use it for while for Lokad.com; but looking back, it turned out to be a really BAD move. I have finally manually removed all the content from my wetpaint wiki (because there is no "Remove my wiki" feature available); and I have migrated all the content to community.lokad.com, a wiki powered by ScrewTurn.

It can be argued that moving to ScrewTurn may not be the optimal solution (they are tons of open source wiki software available out there, see the wiki matrix ); but moving away from Wetpaint is the only solution that can be considered if you fall into the WetPaint trap. Yes, to all the people using WetPaints, I strongly suggest to re-consider and start thinking about moving your wiki somewhere else.

For those who thinks that wetpaint is a "free" wiki, it's not. It's neither free as in "libre" nor free as in "free beer". Wetpaint inserts Google Ads in your wiki without providing a paid subscription plan to remove them. Let's look at the problem this way: if the traffic of your wiki stay low, then any $2/month hosting solution will be sufficient to host your website; but if your web traffic starts to go up, then WetPaint takes 100% of the advertising profits generated by your content. No matter how you look at it, the content of your wiki is worth more than$10/month, the price to get an hosted wiki. As, Jacob Nielsen pointed out long before me, free solutions have terrific costs. If you think that the wiki that you are starting is not even worth \$10/month; then starting a wiki might not be a good idea in the first place.