Open Source Start-Up: Blueprint for Success

Friday Jul 13th 2007 by Matt Hartley
Share:

A cash-strapped open source team can improve their chances by following these principles.

Common sense has a funny way of prevailing, even though perceived business trends appear to dictate otherwise. I am of course speaking of cash-strapped companies looking to cut down on their software development costs. In years past, creating a new software product simply meant having access to a pool of programming talent, enough for a timely release. Unfortunately, this takes substantial time and capital.

The rules have changed as exclusive proprietary development is no longer the only option to meeting the software release deadline. These days, open source development offers an attractive alternative to closed source development expense.

Below, I will outline my blueprint for open source success based on my dealings with various developers and open source companies, as I have closely examined their successes and failures.

Attracting Developers

No matter how impressive you find your open source project idea, the fact remains that it has to offer some kind of incentive to attract outside development help. The best approach is a combination of offering a sense of ownership within the project, and making sure the potential developer(s) knows before ever applying that their efforts will indeed be valued.

Gestures such as simply placing their name next to a public page explaining a proposed bug fix, improvement or new feature idea can go a long way toward demonstrating individual value working within the project development collective. Along with this, coming to them with other ideas or challenges you are facing will also help them feel involved. After awhile, they’ll want to spend even more time getting "their" project off the ground.

One other factor that must be considered is the barrier to contributing as a developer. Does the potential developer need to spell out their life story or await a lengthy approval process simply to contribute to the developing project?

If this is the case, don’t expect the limited number of developers available to flock to your project only to spend the better part of the week waiting to 'meet with company guidelines.' The simple fact of the matter is that this is not going to happen. They contacted your company to help develop a project that they obviously identify with – not to be screened like a common job applicant.

Membership has its Privileges

The final advantage that I think start-up companies have over most "not-for-profit" endeavors is the ability to reward volunteer developers with potential for eventual employment. A large number of companies that 'sponsor' open source projects that later become self-sustaining have the advantage of hiring from a pool of proven professionals, experts who have clearly demonstrated their value without spending any company cash in training.

For example, if I start off as a developer for the ABC Project, hosted and sponsored by ABC Inc., my efforts may one day be seen as valuable enough that I could eventually get paid to work on a project that I am already passionate about versus the job that I go to everyday where I am merely punching a clock. You'd be surprised at how often these circumstances take place and how quickly that person is ready to shift gears in your company's favor.

If offering eventual employment is not something that fits your company profile, perhaps you’d want to consider a strong revenue share instead. If an open source music management application opt to share their music store revenue with me as a developer, based on a development ticketing system that I helped with, therefore giving me a piece of the revenue pie, I’d be quite motivated to continue working with this project!

Offerings like this, much like AdSense, put me in charge of my own future and allow me to make or break my own success.

Building Legendary Software

When thinking of open source success stories, one need only look to Mozilla's Firefox for an example of excellence. Built out of two frustrations with browser alternatives of the day, what would eventually become known as Firefox had timing, passion and an open mindset working in its favor.

If your company is looking to jumpstart development for its software project, take notes from those who have come before you. Study what they did right and what they did wrong. Examine hurdles faced by such projects as Firefox versus Flock..

Why has one become a household name while the other is still building an identity for itself? Despite the fact that Flock is still relatively new, I believe that we should have seen it take off by now if their core mission had a broad enough appeal. I believe Flock is very cool as a concept, however it simply does not appeal to me as a casual user.

Regardless, understanding the challenges and successes faced by each project will save you thousands of wasted man-hours along with countless headaches in unproductive social efforts. In short, stop trying to 'sell' what you believe is cool. Look at what people are asking for and fill an existing need, rather than providing a solution to a self-invented 'need' that doesn't yet exist. This type of effort fails more often than it succeeds.

Sticking to the widest scope of users will always yield the best chance of success. Google hit it big because existing search engines were terrible at the time of its creation. Firefox was a runaway hit because Microsoft (at the time), was not interested in upgrading their Internet Explorer browser. That, and the Mozilla suite was offering more bloat than most people wanted.

Some areas that could prove to be runaway successes today include better non-application specific email spam filtering and improved localized browser bookmark management. Each of these possibilities has wide appeal, and each has largely been ignored or perverted with “Web 2.0” efforts. Most users just want to find what they are looking for, not experience some new 'AJAX-filled' web application that will further waste our precious productivity.

You will know that you nailed your project's full potential when you can summarize the value of your application in three simple bullet points. Again, I point you to Firefox as an example of doing this the right way.

Growing your Community

Excitement is contagious, even when it comes to tiny projects created by start-up businesses. So if your core team is pumped from day one, any potential candidates that might wish to work with you will immediately sense your motivation – and be more inclined to stick with you through the long haul.

The same can be said with your users. In-office video, documenting 'all-nighters' and even flying in your most hardcore volunteer developers for a party, can do wonders to keep things moving full steam ahead on the development front.

With the average user, however, you need to demonstrate a reason why they should care right up front. Flash-whiz-bang-hoopla only goes so far with most people. So get them pumped early, but have enough motivation with your development team, coupled by timely release dates and valuable features that are not soon labeled as vaporware, thus later on ignored.

I would also suggest that maintaining a project blog, staying on top of developer recognition, and seeking out honest feedback from your users are all critical to developing a solid open source community for your product. Enlist help from other developers, as this gives them a voice while preventing you from simply becoming another 'talking head' maintaining a blog.

Also consider other interactive endeavors such as Logo contests, fan-made videos about your eventual beta release and other community driven efforts to further solidify your fan-base. Each of these, when working together, can produce well deserved community buzz that will ensure better project motivation and longevity.

Listen to Your Users - Always

Perhaps the single most important thing to remember when taking your brand new start-up company into the wilds of open source development is that your users always come first. As valuable as the development team may be, without your users, the created software is merely a concept.

So when a user contacts you with an idea, ask for a community vote before deciding whether it’s worth considering. Why? Because your company does not actually own the software you’re helping to manage - everyone who uses it 'owns' it. Making blanket decisions as if this was a closed source application can prove deadly to the successful open source project.

Open Source Works for Those Who Understand the Basics

Many of you considering open source as a development platform have likely already decided that this is not compatible with your company's core mission - making money.

My response? You're right. Even though you can derive a substantial income from open source software, there is no question that closed source offers you money quicker, easier and with much less time invested.

Companies that develop open source applications are demonstrating to their users that they are interested in the application at hand, not just the money. Most open source applications were created around a need, only later to find themselves in a position where income could be generated for the sponsoring company or group.

So when you are drafting your business plan for that next brilliant idea of yours, remember this article. Choose open source development because you are passionate about the software you’re helping to create, not just looking to make a fast buck. Otherwise, your software will age and the interest in what you have created will fade away. Users are often smarter than we think. And they have a nasty habit of seeing through shallow intentions.

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved