Our first Skribit request asks to explore MicroISVs and how they maneuver through the unique challenges specific to being a MicroISV. Let’s start with a definition of MicroISV. The “term was coined by Eric Sink in late 2004 to mean software “companies made up of exactly one person”. Revenue is not a factor – as pointed out in the link above, some MicroISVs have made at least $1 Million.” (Poached from The Business of Software Wiki.)
As a result of their size, MicroISV’s don’t typically have in-house people that are focused on contracts, licensing and negotiation. This role and related tasks fall to the owner, who is typically a developer. They’re concerned with getting their products into the hands of their potential customers, which creates a potential negotiation issue, too. Let’s start with the big issues facing a MicroISV: 1. They can have less leverage because of their size or their “age.”; 2. They can have fewer financial resources able to devote to any legal/contract-related questions.; 3. They usually have fewer people resources to attend to these things.
When you combine a lack of resources and a need to close the deal, the typical MicroISV may feel that they have no choice in contract discussions. Thus, the challenge is to setup your individual situation in a way that gives you some leverage and allows you to not have to spend too much time distracted from your strengths in developing amazing software.
So, here are 3 things you can do RIGHT NOW to regain some control and leverage.
- Remember from our discussions on power in negotiation that simply being at the table gives you negotiation strength. The customer wants your product. If I’m across the table from you, I’ve been directed to acquire it… the only way we won’t is if you’re completely unreasonable. Thus, you’re not at an initial disadvantage as you might believe. In fact, you start with equal footing. So if you are open with me and tell me that you’re small, that you have no staff to do contract negotiation and as a result need to start from your document (see #2 below) but are negotiable, I will probably work with you quite well.
- Be prepared. Pay someone to create a license agreement for you. Do NOT call it an “End User License Agreement” or EULA (this screams “non-negotiable” and “inexperience”). Rather, call it a “Software License Agreement” or “License Agreement.” (Sounds stupid and silly, but it’s amazing what a name change does for the validation of your document.) While I would suggest that you keep it short (10-15 pages in 11-12pt font), make sure that you cover all of the key sections found in any large license document as discussed in the Software License Risk Matrix – otherwise, you’re going to get suggested changes. This is especially true with regards to maintenance and support. If you offer it, make sure it’s all detailed in the agreement. If you don’t, say that you don’t.
- Study the Software License Risk Matrix again if/when you have to negotiate. Go through the Software License Risk Matrix once with your lawyer (or contract professional) and discuss each section, why each section is important to you, what flexibilities you might have and alternate ideas. What you’ll end up with is an enhanced version of the Risk Matrix designed specifically for you and your business. When you talk with someone like me, you’ll be able to articulate your side – and if I ask for something you don’t like, you’ll have pre-considered alternatives to make as suggestions. This will cost you about 5 hours of time and expense. But you’ll be able to recycle the knowledge gained over and over. Then, if the deal is really large enough, and the request unique enough, you’d only have to go back to that professional on a case-by-case basis for just those single things rather than the entire document.
[Shameless plug (this is, after all, my blog): If you need someone to help you with #2 or #3, you know who to call.]