by bonf on 10/19/13, 2:46 PM with 48 comments
However, I wonder if there's anyone here who makes decent money selling software components or code "the old way".
Please share your stories.
(I'm also interested in hearing the buyer's side, so please mention useful code/software that you had bought).
by davidjgraph on 10/19/13, 6:14 PM
We've played around in the SaaS market, in end-user apps that use the component, but we've never found anything that makes even remotely the amount we make from selling the component. A lot of people think SaaS is easier, I personally find it x10 harder.
We ended up gaining far more benefit from giving away the SaaS products as a means of marketing the component.
The thing with the component market is the revenue is far more an "amplification" of the economic environment. You're at the bottom of the food chain, you need new development projects to be started to be considered. Development projects are expensive. In late 2008, budgets were slashed, our component sales probably dropped 80%.
SaaS is much more stable revenue-wise. But on the flip-side, in 2007 when the going was good, sales just soared, it's not only downturns that you feel in the component market.
My advice would be
- focus on building a cash buffer as soon as possible, doing so was the only reason we're still here.
- aim for the Enterprise market, forget three figures a license sales. That level means the component is too simple, something open source will come along and kill you.
- The component market is better for margins and good salaries. The SaaS market generally scales better. Which you choose probably depends what you want to do with the business in the medium and long term.
by pytrin on 10/19/13, 3:59 PM
We have several developers making SV comparable salaries from publishing on our platform (in the 100k$ range annually). I believe this can be a huge market - if you look at companies selling licenses to code or SDK binaries, there's quite a few who built very profitable businesses around it.
Very well known examples of companies selling code licenses include MySQL and Magento (through their enterprise versions), though they provide complete solutions and not components. Gravity Forms (http://www.gravityforms.com/) a wordpress plug-in, is another good example - it generated millions in revenue if you trust their installation counter.
by loumf on 10/19/13, 7:17 PM
Our .NET and Java toolkits sustain a 25 person division with healthy margins and decent growth.
The keys have been:
* make something valuable and charge enough for it so that you can offer great support. If you charge $500, you lose money if anyone calls you -- instead you should want people to call you -- so, charge enough money to make that worthwhile.
* have ways that make the engagement scale. Meaning, it's ok if an average deal is 5-10k, but if someone gets a lot of value, you should want that to scale up to 100k or more
* you can charge like a Saas for things that are not delivered like Saas, and some people prefer it. Meaning, we sell .NET assemblies (not a hosted service), but you can pay xx,000/year for it if you want unlimited deployment.
* You have two segments (broadly) -- companies that make software for themselves -- companies that sell software. They have different needs and get value in different ways -- think about segmentation to price appropriately.
You will be competing against free -- so you need to deliver value. Don't look for markets with no free alternatives. I compete against a ton of open-source very well. We're better and we have support.
by rachelandrew on 10/19/13, 4:12 PM
We don't have recurring revenue as such, a license is a one-off purchase and includes all support, first party addons etc. However our customers tend to be web designers buying a license for each project. If we do a good job they want to use Perch for more than one project!
Growth was slow and steady, I think the toughest part was when we were 50% client work and 50% Perch, as we had customer support making it hard to get on with client projects and we really just wanted to be working on Perch!
by 6ren on 10/19/13, 5:43 PM
Discussion (though might be dying): http://discuss.joelonsoftware.com/?biz
Withholding Tax (if you are non-US, selling to US) "Components" are taxed at 5%; "desktop tools" (like compilers, editors, IDEs etc) are taxed at 0%. The tax is an admin hassle all round, so this is one plus for not selling components. (NB: this is an oversimplification, there's tax treaties, 30% tax if not under a treaty, byzantine IRS forms, tax rulings on the definition of "royalty" for components, etc).
ASIDE an idea: "Software Components as a Service". That is, it's in the cloud and paid for like a SaaS; but the service it provides is not an end-point (like an API to a business), but a transformation - the kind of thing you'd normally call a library for. e.g. text->pdf. Sounds inefficient, but you co-host with AWS/dropbox/heroku/GoogleApps etc so bandwidth is fast and free. (Alt: let the customer install a copy in the cloud, but you charge like a SaaS business model - an advantage for them is they can expense it monthly, not taxed like a capital purchase).
I've seen some evidence of this, in the form of cloud integration services e.g. http://www-03.ibm.com/software/products/us/en/castiron-cloud... (2010), but it's still mostly about integrating end-points, not the bits in between.
by mjn on 10/19/13, 4:05 PM
Another strategy, though from what I can tell with declining popularity, is to write a GPL-licensed open-source library, and then sell proprietary licenses to companies who prefer those terms. Two random examples: http://www.juce.com/documentation/commercial-licensing http://www.cgal.org/license.html
by QuantumDoja on 10/19/13, 3:39 PM
by arek2 on 10/19/13, 5:51 PM
http://5000best.com/tools/Modules/
http://5000best.com/tools/Software_Dev/
http://5000best.com/tools/Specialized/
http://5000best.com/tools/Wordpress/
http://5000best.com/tools/Joomla/
http://5000best.com/tools/Drupal/
by WA on 10/19/13, 3:38 PM
You could regard themes for WordPress as software components. Or theme frameworks such as Genesis (studiopress.com).
The really successful ones (such as Genesis) seem to bundle software components with something like subscriptions to future updates, a paid membership site, additional content like ebooks, live seminars, training, support etc. to get additional income streams and be able to upsell or cross-sell customers.
Game engines or mobile development frameworks (KendoUI, Sencha) that can be licensed also fall under selling software components. Again, the successful ones seem to offer additional resources or they sell their components in a one-year-license model, where customers have to renew the license every year. That would be more or less the same as SaaS in terms of recurring revenue and keeping customers in the loop.
by alecsmart1 on 10/19/13, 5:26 PM
- vBulletin forum (http://vbulletin.com) for the base of my site - CometChat (http://cometchat.com) for adding Facebook like chat to the site - Kayako (http://kayako.com) for support tickets and issues
The advantage I found with self-hosted software is that its one-time. I pay for it and I don't have to worry about a monthly billing. Similar software in SaaS model would cost me about $70-$100 per month. Eventually these costs start adding up. In one-time, I know that my investment is around $500-$800 or so. But that's all then. I can use the software for years without an issue.
by reboog711 on 10/19/13, 4:24 PM
I tried; with Flextras ( http://www.flextras.com ). I wanted to build a set of UI Components which would extend Adobe's Flex Framework. For various reasons it was a failure; and I shut down the "commercial" portion of the company in January of this year.
At the time I launched the business; Flash was still viable and Adobe was pumping a lot of money into growing Flex--which was basically "Flash for programmers". Adobe was trying to grow the user base for Flex to a million developers and I wanted to get in early and ride the wave, so to speak. I thought there would be a market for high quality components that extended the Flex Framework and Adobe stated they wanted to focus on the tooling and infrastructure while leaving components to third parties. I thought I was in a good spot.
When I was preparing to launch Flextras, I was planning for a 70% drop in income [compared to consulting rates] and hoped it would grow from there. I ended up with a 90% drop in income; so that hurt a bit.
We launched with a single component, and the first year only had one sale, and all my energy was spent on building out our Calendar component. [which took a year and I threw everything out and restarted from scratch 3 times because I decided the API/implementation wouldn't provide enough flexibility].
I think it was in our second year released the Calendar component and an AutoComplete component. A "Spark" Version of our AutoComplete came out later to integrate w/ Flex's new component model. Then we released some mobile components. We were growing from our "first year" revenue and averaged about $10K per year before shutting down. The business was growing, but very slowly. Then Adobe had some bad PR mishaps and sales stopped overnight.
I could go on and on about problems and mistakes I made along the way.
I focused on the wrong things--I think I spent three months creating transitions on our Calendar component. Business users don't care about such things [although I got a lot of 'hey cool' during demos]. During this development time; the new version of Flex came out [a point release] which broke all of that work.
The model of selling individual components is inherently flawed. It does not present recurring revenue. I hoped to combat this by releasing a lot of products; unfortunately that didn't happen for a variety of reasons. Components took longer to build than I anticipated [especially the Calendar].
We should have had a package of some sort [one price gets everything we built]. We should have had a subscription [one yearly price gets everything we built; plus everything we will build]. My attempt to switch our business model was a colossal failure on many levels.
I covered quite a bit of the business failures in a presentation called "How to Fail Fantastically" at the 360|Stack conference ( http://vimeopro.com/360conferences/360stack-2013/video/72773... ).
by 6ren on 10/19/13, 5:02 PM
I accomplished this. But it was by definition a stationary target, and competitors (in this case, open source) largely caught up. But worse, I lost interest, because I was no longer "the only/best in the world" at it.
Success: I not only made enough to live on, I made enough to invest in index funds giving a return that was itself enough to live on, and "retire" (for small values of retire, i.e. a student-level lifestyle - "ramen retirement"). Business began in 2000, able to retire in 2004 or so IIRC. Have lived off the business/investments since then.
lessons learned:
- Automating sales (credit card etc) is a pain to setup, but is helpful for both you and customers. But for my case, about 30% of buyers still needed some contact for the sale (I'm not counting technical help). Sometimes to negotiate on specific issues, sometimes they didn't fit the sales process, maybe sometimes they just wanted reassurance that someone was there.- I tried to make it too much a business; if I'd stayed truer to my roots, it might have been OK. If you have an open-source version (or, at least, free), it starves off the competition, leaving them with no oxygen to get started, because no one needs it, they get no interest. And everyone's happy, which actually is very important for one's personal happiness too.
- I actually made a lot of money selling to the enterprise; but I hated it. Like, it really really got to me. In one particular sale, there was 5-6 months of negotiation, admin, international tax laws, etc. Ugh. And it all feels dishonest, pointless, and interacting with people who aren't competent because aren't interested and don't care. (the standard story of a developer dealing with business issues). So, you can do it this way, if you keep going up-market. The enterprise likes old stuff, that is trusted, field-tested, known etc.
- turns out I don't enjoy making a fixed standard. There's beauty in it as a business model; but for a technologist, the fun part is making it (and for me, supporting and debugging was also fun). But when it's all done, all working perfectly, it stops being fun. It's a funny old world.
- the underlying factor is that progress marches on. It's good for the world, and it's fun to participate. But not so good for a self-sustaining business with a competitive moat (Warren Buffett likes candy, chewing gum, soft-drink, bricks, furniture etc - stuff that doesn't change fast). You have to keep investing in it - developing new features, new products, new users (analogous to the capital investment required by the cotton mills of Berkshire Hathaway, making them a terrible investment). But this is all OK, if it's fun for you. And it can be.
by petercooper on 10/19/13, 4:07 PM
by edragoev on 10/20/13, 1:40 AM
If you are single and live in not so expensive place making software components could be a viable business. Just chose something that will not become obsolete in 2 or 3 years.
We are in the PDF space that is quite crowded but still much better than Flash (for example) that is becoming less and less relevant.
If I had to start today I would probably look for some security related stuff.
by libca on 10/19/13, 7:57 PM
The original idea was to create top-notch WinForms and WPF controls (.NET visual components). However, developing single great WinForms or WPF control is pretty challenging task. One need excellent knowledge about the framework and tools. It is much more than programming and deployment. It is also about knowing dark internals of the platform you use.
For example, the greatest challenge was doing seamless Visual Studio integration. Most users didn't know how to add a component to their software. They assumed it will "just appear" in Visual Studio Toolbox window and they just click on it and start using it.
Furthermore, most of my customers haven't just bought the component. They required some adjustments and features here and there. They also needed assistance with implementing the component even though we provided thorough documentation with code samples.
Because of the above reasons, I am currently orienting more on niche components and leaving all the buttons, combos, calendars and other typical controls to big players.
by watersco on 10/19/13, 5:52 PM
by quaffapint on 10/19/13, 6:38 PM
For the little bit the SaaS has been up, people still seem to like the self-hosted version. So, I guess it really depends upon the product and your target customer. There's some things that some people just prefer to host on their own :-).
by fbm on 10/19/13, 4:44 PM
by unreal37 on 10/19/13, 4:11 PM