Slashdot Mirror
Open Sourcing a Vertical Market Application?
BigCanOfTuna asks: "The company I work for is considering the possibility of turning over one of thier enterprise applications to the open source community. They are doing this for a number of reasons including raising thier profile in the OS community, developing relationships with other Energy companies that would be willing to hire us as consultants, and of course just for good will (if there is such a thing in business!). Since the application is very specific to a vertical market, can one expect to see the same results that other open source projects see? Are there any other successful OS projects out there that are geared to a specific niche?"
I think you'll be surprised at how many will want to use your application. There are usually some surprising consistencies between business types which may not occur to those who haven't worked in each. So don't be surprised if your application which was made for an energy company becomes, with a tweak or two, very popular among, say, watch manufacturers.
One of my favorite ideas in marketing was always that you will almost always hit a larger market than your target, no matter how specialized your target. Like Avon's skin-so-soft, for instance. You know, the mosquito repellant?
You might find that people in similar industries will be interested in integrating some particular level of your vertical solution into their own vertical solutions, which will mean they'll componetise them, and consequently make them even more widely applicable and attractive.
Just remember though that if you want to actually see your code used [legally] by commercial interests, the standard GPL probably isn't suitable. While a BSD-style license is perhaps going too far the other way, there are various "creative commons"-type licenses available which retain some degree of responsibility amongst users of your code, without ruling it for them.
Depending on just how vertical the application is, I predict the following:
1) Companies wanting to use it will have a staff member to manage it, who will likely be able to modify code as needed.
2) Assuming the program is internal to the company, it will not be distributed - therefore there is no need to share code changes back with you and the community at large.
So it's likely you will have some users, but few contributers.
But that's based on the assumption that it is of little use to more than a handful of people/companies around the world, and that it is only to be used internally to the company.
-Adam
What the hell is a vertical market?
Koha is a successful open source library catalogue system. Are libraries a vertical market?
I just do not think an OSS vertical will work. The main reason that companies buy vertical app is they do not WANT to know how to use a computer.
A lot of verticals could be writen in Microsoft Access. While I am not fond of Access for a lot of the office management type stuff it would work. People pay for verticals so that they do not have to fuss around with putting it together themselves.
When non computer people get software to run there company they just want it to work and they want someone to call that knows how to fix what ever is wrong or they have screwed up.
Now you could charge for support but then you have to fund the support staff. You have to pay for phones, techs, and clerical staff to do billing.
Finaly how will people ever find out about your program? Are you going to pay to advertise a free program in what ever trade publication that market uses?
Now providing source when you sell a system might be good but if you are doing support how do you support something that somebodies kid has hacked and re compiled.?
I am not saying it can not work but you might be suprised what a HUGE pain in the butt it will be.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Success depends strongly on having a clear definition of success in advance. You can have 100% success if your goal is only to make the code available. You can have complete failure if you have inspecific (which usually means unrealistic) ideas about getting huge consulting contracts and massive participation in developing the code
If by "successful open source project" you mean one with an active community of contributors, I would be wary of a definition of success that depends on the unpredictable actions of as-yet-unknown strangers. In any case, developing and maintaining such a group takes work.
Sure. In fact, the smaller the pond, the bigger the fish you can be -- but it's all relative, of course. Again, determine a reasonable definition of success. Will you feel less successful if only one other organization uses your code (in the short term)? Why or why not? Have you lost anything if no-one adopts it?
Other success factors you mention are getting consulting contracts and raising your profile. These are both possible, but not knowing your industry I won't give you advice on how to achieve them. But again, knowing in advance exactly what it is you want to achieve (and how you are going to measure whether you've achieved it -- especially WRT raising profile) is key.
<sig>Guvf vf abg n frperg zrffntr
You make some good arguments, but you're looking at it from the wrong angle.
His product will not directly benefit other businesses. It will, however, benefit contractors that implement OSS applications within these businesses.
I'm in a similiar position. I have two decently sized applications that I developed and licensed out - there is only one client per each. I would like to see them developed more, and hope someone could use them--perhaps I may be able to make a few bucks down the road as consulting for this.
In reality, I am not really missing out on any income as the chances of someone picking this up and going after a client that I even know exists are pretty slim. I will, however, gain a better understanding of the application itself, maybe make a few acquaintances and hopefully pay back the community that has helped me in so many ways already.
Isn't that what it's all about?
Jason
I just finished a 5 year stint as the lead engineer for a company with 2 vertical market products.
... government accounting, real estate tax billing, etc. There are 3 other companies in the state that were in competition. If you go OSS in a market like this, the other companies will look at your product under the hood, and implement the same features in their product, and turn around and sell it. Thats it. Basically you'll be giving away your intellectual property for nothing in return.
Not every vertical market is the same, but generally, a vertical market application is highly specialized. However, vertical market software is not sold in the same manner as general market software. It's not sold off the shelf. Vertical market software is sold by sales people that understand the the intimate details of the vartical market. The prevailing climate in vertical markets is that when an entity wants to make a software purchase, they contact their sales guy and prepare to spend big money. Since the customer is so focused on spending money, an OSS solution wouldn't even be noticed, even if it's just as capable as the commercial solution.
Another aspect to keep in mind are support contracts. Given the complexity of vertical market software, customer support is gold. Support contracts are king. Without commercial level "hand-holding" support, an OSS application can't compete on that level either.
Vertical markets are highly competitive, even on a regional scale. For example, the company that employed me had software to manage municipalities
Your best chance, if you want to remain in the market, is to not go OSS. If you don't want to remain in the market, you should approach your competitors and try to make a deal, either to sell the client base or license the software to them. If you go OSS with the product, you're out of the market and you'll be throwing away any opportunity to cash in on your existing client base.
Skiers and Riders -- http://www.snowjournal.com
That all depends on the vertical market your application is for. Ask yourself these questions:
1) Are the potential users of this application internet & computer savvy?
2) Are the consultants/vendors to this market more likely to contribute to a project, or to steal the code and never contact you?
We considered open sourcing our temp agency application -- 100% of our profit comes from customizations anyway -- but after analysis realized that temp agencies don't have the know-how to find and install the app on their own, and the other software companies in the market would happily steal our code and incorporate it into their own products without giving anything back (GPL or not). So we've chosen to keep it closed.
However, that varies considerably by industry. For example, you'll find a *lot* of OSS in manufacturing, because many manufacturers have tech-savvy staff, and since service outweighs licensing fees in that sphere 20-to-1, vendors are willing to share.
-Josh Berkus
San Francisco
Let's just say that your company's app is only useful to few people but has a few kickass subroutines that the developers of software that's not related but not a million miles away might be interested in. That's a good exmaple of open source because if they use your subroutines, then they have to do the whole viral thing and improve the breadth of open source software.
Also, don't underestimate - what may seem useless outside your organisation probably has many uses that people have never thought of until they have the freedom to hack it to bits and change things.
catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
Quite a few years ago I worked (as a subsystem owner/guru) for a company which provided its product's source code to the clients. Thus it was limited open source and not free as in speech or beer.
The client base was technically literate (semiconductor manufacturers) and there was only one other competitor worldwide.
The code base was more than 12 years old (at the time) and had undergone much enhancement and change, so it was getting pretty crufty. It took ~24 hours to compile and link from scratch.
Generally, the experience was positive. The clients liked the fact that they could, to a degree, fix their own bugs (which fixes we would propogate to everyone else after appropriate review). It was easy for us to log into their system to perform JIT repairs. They could compile with optional modules to produce a test system to see if they liked the addition before paying for it. And we occasionally got enhancements that we could incorporate for everyone.
The downsides were quite minimal. There was little that the competitor could take directly as the software architectures and structure were too different. Also, one was in FORTRAN, the other in COBOL. As far as copying features; they can do that by reading your product brochure! A couple of companies enabled optional modules in production systems without paying (they got caught when we revamped the DB structure and the automated conversion tools found them out). When the iron curtain came down, we found there were four or so unpurchased systems in eastern Europe.
Great minds think alike; fools seldom differ.
Over time, the business rules/knowledge might be turn out to be the most valuable asset, leading others to make a GNUe module for your vertical market.
Likely? Honestly not. Though I'd check with them just in case there might be a match.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
The best analogue I can think of is the Trust Commerce merchant account API. Their PHP API, for example, was written by one of their clients, and not by them themselves. When I, as a client, needed a feature, I just added it and sent my code back to them for incorporation. I get more features, and they dont have to do so much work! Open Source can really work well in this sort of environment, because it enables players at every end to incorporate the features they would like to see, without leaving the burden on the owner of the software to implement every last thing.
caritj.org
Many Schools and universities use SCT's Banner as a way to manage just about everything in the university--from student and staff payroll, to grades, to financial aid. Banner's source is "open," but not "free as in beer."
The university that I attended uses banner, and the Registrar and others have submitted patches to SCT, and they've been released as patches--either security wise, or as bugfixes.
I'm currently writing an application for web-based management of telephone information, be it LEN's, Pairs, or Routing information. I'm planning on Open Source licensing it, but, I'm not planning on giving my support and time away for free. If a company wants source modifications, they can either a) hire me to do it, or b) hire another perl/php coder to do it. Either way, it's helping the programming/software movement in general, or, it's helping me directly.
I disable sigs...do you?
"Isn't it safer to use BSD in the first place and avoid all this trouble?"
Both the BSD and GPL are based on copyright, and hence the law. There's no way around that. It only seems difficult because you don't understand either one. The best thing for you to do is to have a *firm* understanding of both licenses (or others if you choose to go with a different one), and then ask yourself, what are my goals? Then find the one that most closely matches. Both can have unforseen consequences if there is a mismatch between what you expect, and what they deliver, so make the effort to get it right the first time.