fusenet’s employment/entrepreneur program

A very interesting story in IT World Canada about a company called Fusenet that has put into place a novel approach to business. In effect, it is empowering its employees to become entrepreneurs and giving them equity in their creations. Fascinating approach. Inevitably comparisons can be drawn with a similar program Google runs, but as far as I’m aware Google retains ownership of everything created by its employees. Not so with Fusenet’s model. From the article:

Every Friday, the Pet Project Program (P3) goes into effect. “If you’ve been approved into the program, on Friday, we don’t expect to see you at your desk. You’ll be in our lab or you’ll be collaborating with other people,” said Singhal.

The P3 model is codified into employee agreements and the intellectual property developed during this time does not belong to Fusenet, he said.

If an employee spends three months working every Friday to develop a new technology for better video compression, for example, and then presents it to the company, the idea still belongs to the employee, said Singhal.

Fusenet will ask the employee how much they want to sell the idea for or whether they want to start a company that will sell or license the product, he said. “We’ll help you market that and say, ‘We’ll take 50 per cent of the equity, you take the other 50 per cent,’” he said.

“We will help you with money, we will give you all the resources you need – marketing, customer service, R&D – but you get to keep a significant chunk of the equity in the business as opposed to having just the pride of being able to say you started it,” he said.

The policy applies to all employees, but it’s the software developers who are most likely to come up with the ideas, said Singhal. “We thought this was an interesting model … 99 per cent of the companies out there will take the software,” he said.

Fusenet has experienced one major success, one emerging success and two failures as a result of the model, said Singhal. Another five projects are currently in the R&D stage, he said.

Of course there is a caveat noted in the story about how such an arrangement must be carefully documented. I could also see a few risks associated with this as far as delineation of IP and who owns what. Very often, when new ideas spring up, they may be closely related to some existing intellectual property or based upon it. The question then is where the dividing line is or should be drawn and how that is set out in the documents. Not an insurmountable issue but one that does warrant a bit of thought.

I certainly admire Fusenet for having the vision and courage to adopt such a model. Of course, it’s no guarantee for success but certainly puts all the right incentives in place to have an environment conducive to that. I really do hope to see some interesting things come out of their shop in the near future. They will, after all, be very likely to attract the right sort of folks with this program.

The Virtues and Evils of Open Source – Part II

Found the article that triggered my previous post – was a piece written by Suzanne Dingwall Williams in her blog. The nub:

If you want to sell your own proprietary software, make sure you have a strictly enforced policy against using open source. Here’s why: even if you agree that open source has crossed the chasm in the lifecycle that is technology adoption, your investors have not. Even the inclusion of an inconsequential open source tool can cause headaches, or stop a deal altogether.

Here are the concerns often raised about open source at the due diligence stage:
– there is no meaningful warranty or indemnity for this portion of the product
– how do we know the open source license is enforceable?
– do the terms for this piece of open source contaminate the rest of your product?
– if this was inadvertently incorporated into the product, what else was?

I should emphasize that I don’t necessarily disagree with the concerns she notes. They are concerns. Particularly in the specific instance she notes – i.e. selling proprietary software (as opposed to using an open source business model). That being said whether or not the benefits will outweigh the risks will depend on many things, including the business model of the startup (even if one chooses to go the route of developing proprietary software), the license governing the open source code and of course how its used. I don’t necessarily think that companies (including startups) should just have a flat policy not to use open source. But I’ve already rambled on about this in my previous post.

But then again, I’m not a VC. And Suzie apparently used to be one. It would be interesting to know what VCs generally think. Are you a VC? If so it would be great if you could go to the poll at the bottom of the left column. Nothing super scientific, admittedly, but I’d be interested in seeing what the general sentiment is.

The Virtues and Evils of Open Source

Yes, I know, I’ve been behind lately. A ton of very interesting things to catch up on. But I’d like to put in one quick note about open source code. I recently came across an article, written last year by a lawyer, generally advising development companies not to use open source. I don’t quite recall where it was (if I did I’d link to it) but I do remember it being quite clear in stating that using open source is A Bad Thing and to avoid it altogether – not just to be careful, but rather to treat it as one would radioactive waste.

With respect, I don’t quite agree. I certainly advise my clients to take a great deal of caution in using open source code, particularly the GPL variety, and very particularly if they have a desire to keep some or all of their own secret, proprietary code secret and proprietary. That being said, I do have many, many clients who have used open source code to great advantage in various ways. Some have simply used existing open source code to avoid reinventing the wheel (and saving on costs), while taking care to keep viral elements out of their proprietary code. Others have been more aggressive with the open source model and have intentionally decided to use open source as the basis for their business model and making their very own code, or parts of it, either open source or subject to a dual-licensing model. As the Red Hats, JBosses, Sleepycats, MySQLs etc. etc. of the world have demonstrated, you can go open source and still have a pretty viable business. And, of course, there are the “old world” companies like IBM who have decided to go open source (in some limited ways – e.g. IBM’s DB2 Express-C thing).

Of course, this is not to suggest that anyone through caution to the wind and just start pulling down stuff from Sourceforge and whacking it into your product. Use of open source definitely requires some planning ahead and consideration of what the business model and value proposition of your business will be. Optimally, enlist the help of a lawyer who’s familiar with open source licenses to discuss what you plan to do and the packages you plan to use. Or, if that’s not feasible, try at least to read the applicable licenses yourself and ensure you comply with them, because if you don’t think that anyone will notice, or that no one will actually sue you, you may want to pay a visit to the GPL Violations Site and reconsider, in addition to the questions that will be asked of you when the due diligence starts on your next round of financing or, even worse, your (aborted) exit event. Can badly managed open source usage (and I emphasize badly managed, not simply open source usage) kill a deal? Definitely.

In short – I don’t think open source is necessarily a bad thing. In fact, it can be a pretty good thing, not just in the social good sense and all that, but also as a business. But it need to be used taking into account its terms of use and ensuring that its consistent with the strategy you plan to take.

If perhaps there’s one thing I’d recommend it would be for shops to make absolutely sure they have a disciplined approach in tracking where code comes from and the terms under which its being used and why its being used. That applies not only to open source stuff, but also, for example, your programmers taking neat snippets of code from Dr. Dobbs or something else, or coming across a nice little script somewhere on the Web and saying “Gee, that’s neat, let’s use it in our product”.

Anyway, if I remember where the article was I’ll update this to include a link.