OUR NETWORK:CompTIA TechLore DijitCommunity TiVoCommunity MyOpenRouter About UsAdvertiseContact Us
The Largest Online Community
for Software CEOs and Executives.

 
Learn about scoring Forum's Raw Score: 8992.89
October 28, 2003 01:59 PM

Categories: Marketing and PR

Rating (0 votes)
  • 1
  • 2
  • 3
  • 4
  • 5
Rate This!

Member Avatar

mderdem

Member
Joined: 09/22/2003

Hello,

We are in the process of developing a software piece which has open source competitors. According to my findings our tools have advantages like being supported and more powerful and complete in terms of features.

However I am not sure how to convince the potential users to use our software. While there are definitely advantages which are specific to the domain and software, I would like to learn more about general valid arguments against open source software ( which are not complete and professional solutions yet ).

Thanks in advance,

Discussion:    Add a Comment | Comments 1-16 of 16 | Latest Comment

October 28, 2003 3:00 PM

Oooh, great question -- sorry I don't have any great answers.

If I were in your shoes, though, I know I'd read "Open Source: The Unauthorized White Papers", by Don Rosenberg, ASAP.

It's a great book, in that it skips the technical proselytizing and gets right to the business issues: How software companies can derive revenue (or not) from open source.

Next, I'd try to find other software companies competing against open source, and call them up. Find out who the VP marketing is, and introduce yourself -- most are willing to share.

(Of course, I hope the same thing will happen here, in these forums...)

If your end-users are consumers, I suspect you will have a battle -- depends on how important the reliability and standards cards are in that deck.

In the business world, I think it will be a bit easier: Many corporate users still find open source suspect, and they always want to have someone to call -- i.e., you.

As you know, this is how Red Hat has made a nice living selling open source: by positioning themselves as the corporate security blanket.

October 28, 2003 7:43 PM

Take a look at CIO.com. They've done a good job of analyzing the issues involving use of open source software.

Here are a couple of issues to get you started:

1. As you mentioned, support, training and consulting services are critical. You are committed to supporting and providing services related to your software. Who is providing these services for the open source software package they are considering? Is the firm providing those services stable; will it be around for the life of the software? Do they know the software they are supporting as well as your engineers know yours? How responsive will they be?

2. The license is not the only cost related to software acquisition. In many markets, it's a tiny piece compared to integration. Do a total cost calculation for your prospects. They may see that they aren't saving much.

3. With open source the user has very little control over how the product evolves. You can make the case that they will have more input with you.

4. If they are embedding this software in products they intend to sell, using open source software has licensing implications. You need to make sure they understand what type of open source they are looking at and what it will imply for their revenue generation.

5. If they are going to modify an open-source application for their own needs they will have upgrade issues. If your software is flexible enough that it can be configured instead of requiring code modifications, you may be able to point to a cleaner upgrade path.

November 4, 2003 1:50 PM

Hi

I run a high tech services company that inspects buggy code. As part of my marketing I have a run a series of detailed analysis comparing Open Source to Commercial code. I have several white papers on the subject and you can find them at my site at Reasoning.com

-Bill

November 6, 2003 11:05 AM

Other than having a superior product, excellent support and proven quality through a large list of happy clients, I'd say one of the big things that we can offer a corporate client that most open source software cannot is the ability to sign an NDA (and be trusted to honor it). If a client of ours has a problem and they need us to go in and fix it, they can have confidence that we won't give away their secrets. Many open source projects use newsgroups or public message boards for support, and the client would have to post (possibly critical) information on a public forum to get help.
Greg

November 6, 2003 2:25 PM

Great point, Greg -- will be a key issue for all b2b customers, and worth highlighting in marketing, because it plays so well to FUD: "Sure, open source is fine, as long as you don't mind every hacker in the universe prying into your company's data and difficulties..."

November 9, 2003 6:55 PM

Hi,

Does your superior service, additional features, etc. matter to the CUSTOMER?

If they do NOT matter then, unfortunately, there is no reason for the customer to choose your product.

If they DO care about some or all of the above then it's a matter of communicating that to them.

There are MANY instances where a free program is lacking in usesability, etc. and someone will pay for a program that meets thier needs.


BTW, very very smart to START with those marketing questions. Until you can answer the question "why would they buy it", then you're potentially wasting a lot of resources on development.

View unverified member's comment - posted by memphishank

November 18, 2003 3:48 PM

Originally posted by Entrepreneur
Hi,

Does your superior service, additional features, etc. matter to the CUSTOMER?

If they do NOT matter then, unfortunately, there is no reason for the customer to choose your product.

If they DO care about some or all of the above then it's a matter of communicating that to them.

There are MANY instances where a free program is lacking in usesability, etc. and someone will pay for a program that meets thier needs.


BTW, very very smart to START with those marketing questions. Until you can answer the question "why would they buy it", then you're potentially wasting a lot of resources on development.

These are all excellent points. We find ourselves in this conversation with customers every day and the key points we've been focusing on are:

1. We're more responsive to meeting business needs than the open source project we compete against. They often favor technical elegance over understanding the problems customers are trying to solve. We can deliver new functionality in a fraction of the time they can/will.

2. We have fewer vulnerabilities. This is a big one as we produce tools to secure access to the network. We have engaged third parties to "beat on" our code and discover potential vulnerabilities to demonstrate our commitment to delivering a solid product.

3. Predictable releases. Another big issue, especially for large organizations. Open source releases (at least in our space) tend to be irregular. Sometimes there is a long wait between releases and other times there is a flurry of release activity (especially after a vulnerability is announced). Our customers need to be able to plan deployment well in advance.

4. No patching! The "cost" of free software comes after adoption. We have a number of customers (especially in the financial industry) who have had to reassess their commitment to open source software when they came to realize how expensive and time-consuming it is to manage patches and recompile binaries with each release. As the open source community often relies on third parties to provide extended functionality, there's also the cost of testing the third party patches against the new source code to make sure nothing has broken (which it regularly does).

These are all real concerns that have to be factored into the purchase equation. The more you can do to make these issues part of your marketing and sales conversations with prospects, the more successful you can be.

November 18, 2003 3:56 PM

Sounds like a job for a White Paper you can give away to prospects. Use a contract writer if you don't have the time yourself, or "don't know how to write a white paper."

November 18, 2003 5:13 PM

Have your customers analyzed their Total Cost of Ownership with this sort of software?


E.g., Linux might have a zero aquisition cost, but then you have the cost of:

1. ReTraining Windows users in the basics of Linux.
2. Retraining your IT folks (who probably alread know Windows) in Linux
3. Cost of FINDING device drivers for unusual hardware.

I'm not saying Linux is a bad choice of O/S, but merely that there are other considerations besides aquisition cost.

In OUR case, we provide therapy software. It's 5x the cost of educational software. However, educational software isn't designed for patients to use INDEPENDENTLY. And it's not designed for ADULTS.

Sometimes free is NOT a good price.

(Hmmm... good title for a white paper, eh?)

January 22, 2004 6:30 AM

Hi,



We've been up against free open-source for nearly two years, and have learnt many lessons, most of which have been intimated here.

Of course, one would expect that it wholly depends on the product. Where that product is likely to be installed by a techie, used for a very specific purpose/timeframe, then you need to think hard about how you'll differentiate and thereby provide value (support, stability, kudos - some management need to pay SOMETHING or its all a little suspect.). When a market matures and you reach your early majority, your customers start asking questions about manuals/support/installation and this makes it easier than ever to differentiate and pick up the loyal customers.

Side note, I wouldn't worry too much about the vulnerability a corporate customer will feel in a forum, it hasn't stopped government departments and major banks submitting their requests in our case (and they have the necessary anonimty anyway).

The most 'tangible' items will set you apart from an open-source competitor (e.g. application of a professional UI, which sometimes is neglected given the tendency for open source to focus on feature not ease of use), manuals, ease of installation, boxes (if you go down that route), a singular personality behind emails/promotions.

Now, the truly enlightened software marketers among us will know that in fact open source is NOT actually competing with your sales dollar, in fact it is enhancing it. Open source products are your proxy word of mouth, and users that are sick of no support and with $$ to spend will naturally migrate to a commercial option. Those without $$ will go the open source route, but they were never your prospects in the first place.

Regards,
Ben Prendergast
http://www.copperproject.com

February 24, 2004 9:37 PM

I visited www.machsim.com. Are those products that you're referring to? If yes, I can see that they are unique.

I'm selling PHP scripts. Sounds tough, right? At first, I was so worry how can I make any sales as there are so many open source scripts out there, free and powerful. However, there are a few things that I have learned so far.

1. There are always a niche where people are willing to pay for good scripts. Good scripts not necessary mean to have a lot of features but meeting their needs.

2. Consumers feel secured and comfortable with the price they pay to guarantee the full use of the products.

3. If they use your products to make money somewhere or as a part of their businesses, they are willing to pay but not depend of FREE things which will turn their businesses away at the end.

February 25, 2004 8:06 AM

Ben and C made very good points above.

Simply put: if your product can save the customer TIME, MONEY, EFFORT, etc. compared with the alternative (free software, paper solution, competing software, etc.) then they'll pay.

The challenge become COMMUNICATING how you achieve the above. This is called DIFFERENTIATION.

SUGGESTION:
1. Sell one on one for a while (over the phone, in person,whatever - just TALK the the customer)

2. Once you figure out what issues your customers care about, then you're ready to turn the prototyped sales info from #1 into reproducible marketing literature.

Sometimes our product has a direct (or indirect) benefit that we never thought was important, but it turns out to be very important to your cusomer.

February 25, 2004 11:15 AM

I'm at a company where we've recently made a decision to change our business model from a traditional software model to an open source model.

So this posting is about how open source companies try to compete with traditional software companies. (You can either decide to join the open source shift, or at least know how a good open source competitor is positioning itself against you.)

Our company is doing this because we have decided that in our industry (IP PBXs) we need to "change the business model" in order to profit from the shift to VoIP, and reach a market-dominant position.

After analyzing what it takes for our business to succeed, we have concluded that comanies like RedHat, JBOSS, MySQL, and others have demonstrated that a successful business model can be built on providing supported versions of open source code.

The key to this business model is that our company needs to supply the following things to business customers:

- Stable, predictable software distributions. While the open source effort has daily builds and numbered releases, a key value a company like RedHat/JBOSS/etc (and our company) provides is to exercise its judgement about what elements of the open source should be included in a given "release" of our software distribution. These distributions are also supplied at predictable ("roadmap") intervals, just like "traditional" software vendors. Enterprise customers rely on open source "companies" to tame the (potentially) wild and wolly open source code base. In addition, by providing well known, well marketed release numbers, it also provides a well-known "target" that other partner products can shoot for. In our case, for instance, we can tell customers that Vendor X's IP phone will work with Release Y of our software.

- Business-grade technical assistance. Customers that purchase subscriptions become entitled to receive technical assistance from our customer support organization. The customer should see no difference in the level of "support" they get from an open source provider as they receive from a traditional software vendor.

- Professional services. In our market, there is often a reasonable amount of work that needs to be done with customers to plan for, and install a system. Our company supplies a robust program to support this.

- Training. Because operation of an enterprise system is most successful if the customer has trained administrators & users, we provide training required to do it.

- Continuing software development. Our company *continues* to do software development, but all development is then placed into the open source distribution. Our development is targeted at addressing key issues required by customers that the open source development community may not be addressing. Examples include simplified installation, specific features or management capabilities, etc. In this way, customers get the best of both worlds -- the benefit of the rapid development that characterizes the open source development community plus the focus of a software development organization that is directly responsive to customer needs.

It has been a very inspiring time for us to shift from a traditional model to an open source model. Our larger enterprise customers are totally "sold" on the positive value of open source, and have not only embraced the strategy, they have in many cases indicated that some of their own internal development staff spend a few cycles developing new things to contribute to the open source community. And our experience in the "community" has been surprisingly positive as well - we know of developers who want to go tackle many of the technical things we wanted done but could never get to, thus providing a much more competitive solution to our customers.

I have come to the following conclusion:
- The 1990's were characterized by the ability of software companies to cut their development costs by using offshore development;
- The 2000's will be characterized by a fundamental shift from the software business being driven by the "traditional" software model to seeing companies that understand and leverage the open source model dominate the segments in which they compete.

I suggest companies go look hard at how open source companies are operating. It takes a BIG mind shift to wrap your mind around what it takes to run an open source company. It takes a complete re-wiring of your brain if you've been in the traditional software business for years. But you should look.

-jb

February 25, 2004 12:51 PM

I'm pretty agnostic on the whole open source thing. In my experience, with programs written via open source (sourceforge, etc.) the programmers are smart and very motivated to enhance the product. However, they also don't seem to really understand the probelms they are solving.

E.g., half of the difficulty of programming is understanding the problem you're solving. That takes a lot of hard thinking and talking to customers. That happens in OS if the program is intended for other sw developers to use. Not the case, generally, with a generic commercial application (word processor, knowledgebase, etc.).

But.. it's no skin off my nose whether there's lots of os software out there or not. Doesn't affect my software company (our challenges aren't software related. They're business challenges: marketing, etc.)

But my question is...

How do the open source developers support themselves while writing all of this code?

Do they just do it as a hobby/sideline?
Or perhaps to learn more about coding, etc.?

February 25, 2004 1:08 PM

Entrepreneur raises several points I want to address.

1) Do open source projects address customer needs the way traditional software does? This depends on the way the open source code is coming to market. If it's a sourceforge project done by some interested individuals, it probably only meets the needs of that developer. However, many projects actually have a corporate umbrella -- like RedHat, JBOSS, MySQL, and others -- that continue to do software development that they focus on specific customer needs (prioritized by sales people, as in traditional software models). These people "understand the (customer) problem" they're solving, and address it. They just put the resulting code into open source, so that it can be built on by others, too. This therefore can be applied to both "generic commercial applications" as well as software that developers use.

2) How do open source developers support themselves while writing the code? This goes to the same question -- what is the business around the open source? The other "commercial" open source projects I mentioned above all have models that self-fund. I'd recommend going to the JBOSS website, and reading the articles about open source written by the founder of JBOSS. JBOSS is an organization that, as a commercial activity, does contract solution programming for customers, using the JBOSS open source framework as their coding tool. Thus, JBOSS *software* becomes advanced in conjunction with the consulting work JBOSS does. MySQL does something slightly different. They use differing open source licenses (GPL / LGPL) to create a method for them to license the MySQL database software to companies that want to embed it into their products without "tainting" their products with a GPL license.

In our company's case, we are a venture-backed company. We've spent $25 million in VC money building our software. Now, we're taking it to market using an open source model.

So the way in which open source gets created isn't the same as the traditional model. It nonetheless can be effectively created to meet customer needs.

-jb

Discussion:    Add a Comment | Back to Top | Comments 1-16 of 16 | Latest Comment

Add Your Reply

(will not be displayed)

Email me when comments are added to this thread

 
 

Please log in or register to participate in this community!

Log In

Remember

Not a member? Sign up!

Did you forget your password?

You can also log in using OpenID.

close this window
close this window