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?"

Comments

Rifles and shotguns

[Mattcelt]

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?

I predict two things:

[stienman]

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

Re:I predict two things:

[jrstewart]

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.

Legal obligation is only part of the reason to contribute to an open source program. Another huge one is not having to maintain your own set of patches against the main app. Then there's the idea of community - if you share you'll cool features hopefully other people will too. These are sound arguments that businessmen understand. They all lower your local development costs.

I only have one question

[iCEBaLM]

What the hell is a vertical market?

Re:I only have one question

[revmoo]

What the hell is a vertical market?

I think it's "lingo" for the drug trade, but having a day job precludes me from being familiar with the language of "the streets" and as such I am not "down" with it.

Re:I only have one question

[LWATCDR]

Vertical Markets are small niche markets. Some exmaples would be.
Storage Building managment.
Doctors Office managment.
Video Store.
Auto shops.
Software for these are called Vertical Applications.
Guess what you can make some very good money in Vertical markets. You will never be a Lotus or MicroSoft but you can make good money.
Horizontals are things like Paint programs, or Spreadsheets. Things that almost everyone can use.

Re:I only have one question

[stienman]

For the Google Disabled:

A vertical market is a particular industry or group of enterprises in which similar products or services are developed and marketed using similar methods (and to whom goods and services can be sold). Broad examples of vertical markets are: insurance, real estate, banking, heavy manufacturing, retail, transportation, hospitals, and government.

Vertical market software is software aimed at a particular vertical market and can be contrasted with horizontal market software (such as word processors and spreadsheet programs) which can be used in a cross-section of industries.

Taken from here.

I personally like the "Broad example of a vertical market" phrase...

-Adam

Verticals.

[LWATCDR]

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.

definition of success

[turg]

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.

Since the application is very specific to a vertical market, can one expect to see the same results that other open source projects see?

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.

An Argument for OSS.

[jfisherwa]

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

Depends on the Application ...

[TheFuzzy]

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

Re:Use of components

[Mr. Slippery]

You should avoid the GPL if you want to reuse components (libraries for instance) in further commercial products. BSD license is better suited for this.

You're confusing "commercial" (selling it) with "proprietary" (keeping the source secret).

Putting that aside for the moment, why do you believe this to be true?

If I create a library that I wish to use in both open source and in proprietary products, GPLing it does not prevent me from putting it in my proprietary product - as copyright holder, I can do what I want. GPLing would prevent someone else from an "embrace and extend" attack, which BSD style licenses don't protect against.

If I want others to be able to link my library into their own proprietary apps, I can LGPL it.

GPL or LGPL doesn't prevent me from reusing my own code in a proprietary fashion - it prevents others from doing so. It would seem to be entirely to my benefit to use (L)GPL over BSD in such a case.

Community Benefit

[bbtom]

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.

My Experience with This

[Mikkeles]

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.