Tuesday, June 26, 2012
Technology: outsource vs open source
I wrote this note a few years ago when my then employer — a tech company trying to get into retail — was considering outsourcing tech and laying off all tech employees. I didn’t like the idea, but as the manager it became my responsibility to give it a fair evaluation, so my team met several outsourcing providers over a few months. Every single one of them looked at our work and said they couldn’t build something like it in the same period with a similarly sized team. In other words, they were neither as fast nor as cheap as the internal team was. They also balked at the company’s condition: since we didn’t have any money, we’d pay them a share of our retail revenues rather than a fixed upfront fee.
The more I considered it, the more I was convinced it was all wrong, but the company’s management was insistent. People were leaving anyway: the rumours and the delayed salaries — thanks to the credit crunch of 2008 — were more than they could take. Eventually, I quit too.
I don’t think I ever sent this out. This was my private note to prepare for face-to-face meetings.
We are planning a model wherein we don’t pay the partner but give them a share of revenues. Why will they agree to this unless they have a stake in the company’s management? We’ve seen how [redacted] has imposed themselves on our ability to make independent decisions. What’s to say that the outsourcing partner won’t do the same, especially given they aren’t paid to take orders?
Software development structures are based on three variables: people, processes and machines. People are the hardest variable to control, so structures of scale tend to emphasise processes and machines (faster machines to compensate for more inefficient code). [Employer] has a known problem with tending to people. Rather than fixing this problem, we’re outsourcing it, even as management literature consistently emphasises the need to focus on people in an organisation that is establishing a [new] business (rather than scaling an established business).
Outsourcing case studies consistently point to how selecting members of an outsourced team is nearly as hard as hiring them oneself. If we expect rapid turnaround from a technology team, we’re not going to get it unless that team is staffed by the brightest minds around, using technology that we believe most appropriate for our required agility. This is antithetical to how outsourcing partners achieve their scale: by emphasising process over people.
There are advantages to outsourcing in terms of training and retrenchment costs, and of the individual affording focus on their technical career, but on the whole I remain unconvinced this model actually works.
An alternative that I find more agreeable is to liberate from company confines the technology rather than the individual. Most of what we do has a high degree of overlap with the rest of the world. If it didn’t, we wouldn’t survive as a business. We exist to gain from the small differences in practice. The technology we require, similarly, has wide application elsewhere. Technology, whether hardware or software, is affordable when mass produced. Mass production is the only model that allows high intellectual input while keeping the output affordable. Among the chief lessons from the open source movement is that software that serves as basic infrastructure gains higher quality at lower costs when liberated from the confines of an organisation.
This is the way our approach to outsourcing should work. For every requirement, adopt an existing piece of technology and add the necessary polish. For anything that doesn’t already exist, create it and give it a life beyond our own limited requirements.
Putting it to the test
I took a year off after quitting and spent much time mulling over what eventually became HasGeek. I had a bunch of ideas on how software ought to be built, and it was only fair that I do this at my own risk. My first project at HasGeek was DocType HTML5, for which I wanted to rethink how events are organized. Part of this was to make an interactive website that handled attendee management rather than doing it offline with spreadsheets and direct email and phone calls. As I wrote the code, I found myself having to make the choice I had outlined earlier: should I keep this code to myself, since this was the crux of a new business, or should I give it away and encourage others to adopt it and contribute?
I agonized over it for a few days, then decided the business hat I had worn for a couple months couldn’t override the developer hat that had considered this decision for a decade. I released all the code under a liberal BSD license. If you don’t know what a BSD license is, it essentially states that you can do anything you please with my code without informing me, just as long as you credit me as the original author.
You may imagine one of two things happened at this point:
- Developers jumped into the code and started contributing new features.
- Competitors stole my code and competed with me at far lower costs because they didn’t have to pay me for the code.
The reality? Nobody noticed. Not initially, at least. Then an event attendee chanced on the code and sent in a patch. He added an iCal entry so site visitors could save the event date to their calendars. A student copied my code to build a website for his college event. He put my fledgling company’s name in front of a new audience that I did not have the budget to address myself.
Two things did not happen:
- Nobody looked into my code to find a security flaw, to use it to break into my website and steal all my data.
- Nobody used my code to build a competing business.
Encouraged by this, I built my second project, the HasGeek Job Board, completely in public. The code has always been open. I was running a bigger risk this time. This wasn’t an event; anyone could put up a website with my code and outspend me on publicity. I was nervous and refrained from linking to the code from the website.
I put out an initial test release to get some feedback. What happened next blew me away. People started using it almost immediately, and even better, started reporting good results. The board got some 3500 unique visitors in the first month. Today it’s at over 11,000. Status report:
- Over 70,000 unique visitors in the past year. 11k a month and growing. 60%+ returning traffic. We haven’t spent a paisa on advertising it.
- Daily reports of people hired via the board. Thank you emails.
- Indirect revenue via our events, which was the goal in the first place.
- HR consultants and other parasites who find this a goldmine of companies that are hiring, but have lost out on the flip side: access to candidates looking for jobs. Candidates don’t need to talk to a consultant when they can apply to the company directly.
For the first few months, I regularly compared the board with others that targeted the same audience. They were tied to media properties with a bigger audience and I had no monopoly on good looks or usability, so I had reason to be nervous. They didn’t seem to be doing well. I saw announcements that they were going to relaunch soon and it would be fantastic. Nothing of the sort happened.
Nobody stole our code and competed with us.
The first person to contribute a patch got hired and became HasGeek’s first employee. HasGeek is now six people. If you’ve never seen us advertise on our own job board, that’s because we don’t have to. We simply hire volunteers who contribute to our code. It works great: we don’t need a ramp up period to get them familiar with our systems, and we don’t need to create fake scenarios for interviews. They are demonstrating capabilities with production code.
Someone stole our UI and put it on top of their own code. The job board’s UI is a skeuomorph: it mimics the visual appearance of an older medium while neither reproducing its usability nor having the constraints that defined the original look. A sticky note gets curved because of the way paper bends. There is no reason to have curved shadows on a web page unless you are trying to evoke the emotions of working with paper. This rip-off site was a skeuomorph of our interface. It mimicked us but didn’t function the same way. I sent them a copyright violation notice because our code is open, but our identity is not. They didn’t respond, but it’s been a month and the site no longer works.
Some folks wrote to ask if they could fork the code for their own websites. (You can! Just do it, don’t ask!) Their patches are making their way back upstream to our code. I’m glad because it means new functionality without having to invest in new code.
After the job board, I made it a policy that all our code henceforth will be open source unless there’s a very good reason to keep it closed. We ask ourselves this question with every new project. Every one of the 30+ projects so far has remained open. The number of contributors is growing. We’re days away from releasing a project that is almost entirely built by volunteers.
We’ve gotten this far with zero equity financing, relying entirely on revenues and some debt to ease cashflow. We pay salaries. We even pay volunteers who commit to delivery. This money comes from our events, and the events are powered by our code: code which saves time and therefore finances the production of more code, rather than being spent on event logistics.
Will this last forever? I don’t know, but it certainly works right now. Nobody’s used our code to gain a cost advantage while competing with us. Releasing code has reduced our own cost of operations.
If you are struggling with the cost of producing code, or with hiring talent to produce it, ask yourself this: why is your code not open source?
(Comments are closed because this blog gets more spam than I can handle, but you can respond over at HackerStreet.)