Skip to main content
Welcome guest. | Register | Login | Post

Dare To Dream -- The Perfect Open Source Startup

14 replies [Last post]
supermike's picture
Offline
Joined: 2006-02-17

Dare to dream. Imagine you have been given enough living money for you and your family for a year. You have great programming skills in a language of your choice. You're a Linux fanatic and you're almost finished with a fantastic FOSS project and have more on the white board in the planning stages. What happens in the months ahead as you try to come to self-sustainability in a year?

After two years of self-sustaining profitability and then some, what does your new company look like? What kind of manager will you be when you hire new employees? What will make your company better than the traditional model of company? What will your software development office be like?

ma_d's picture
Offline
Joined: 2006-07-07
Making Money

The thing to do in the final months is to figure out how to make money off your FOSS project. Will you try to sell support? Will you sell builds? Will you hope people donate (a bad idea)? Charge for admission to a support forum and let the community pay to support itself? Build software on top of yours which is proprietary and sell that?

Once profitable I'd likely sell the company to someone I believed I could trust to manage it with the agreement that I become the lead developer. Who wants to manage a company anyway?

I'd probably stay there for a couple years, until I decided the company was either dying or growing too large and move on.

supermike's picture
Offline
Joined: 2006-02-17
Sales

I was thinking the sales model would work like this:

* Release software for free download that is one major release behind but not any minor releases behind. There's a small purchase option for the latest major release. The download link is prevented from being hijacked on another site and requires a captcha. The download link also has a random URL that changes in unpredictable ways in order to thwart those who just want to hijack the link.

* The process of getting the download link puts the customer through two pages that are a mix of Google AdSense ads and my own shameless advertising.

* One can purchase the CDR media with the latest version of the software along with receiving the end user and hosting management documentation, and a T-shirt for shameless promotion.

* One can purchase the SDK which includes the CDR of the latest software, all the documentation including the thick developer's manual, and a T-shirt.

* One can purchase the two-DVD set to watch the developer training video.

* One can purchase the bundled rackmount CPU with the Ubuntu Server OS and software that's ready-to-go as is or with custom development.

* One can purchase technical support blocks. Originally this is done by email, but eventually this is both 9-5 phone support in addition to email support.

* One can purchase offsite and onsite consulting and developer training.

* Every page of the marketing website has Google AdSense ads.

libervisco's picture
Offline
Joined: 2006-05-04
So basically the software

So basically the software is Free (not restricted), but you distribute the latest major version for a fee (to make money) and older versions for free? The latter can actually serve to keep the incentives down for someone to upload their pay version before you release it for free. You also bundle additional service with the pay version.

Sounds good to me all in all.

About the question of what would make this company better than a traditionally modeled one, I think just the fact that it seeks its profits in surrounding value added services rather than selling licenses (or renting) software is one positive differentiator. Some others may include being open about your practices and progress, providing for a creative environment and atmosphere for your employees as much as possible, advertising yourself as a human small business growing out of a community so to speak (well, you are participating in these forums and asking ordinary people like us for opinions Smiling ). For example, you could have an official company blog where you would keep people updated about the progress of things, the new things you are working on, new releases etc.

The blog should be friendly and you should also use it to convince people that the pay version is necessary and good for the product and the company and create the kind of atmosphere in which people will not actually want to upload the pay-for (latest) version to a public server essentially bypassing your distribution channel, out of understanding and respect for your company.

supermike's picture
Offline
Joined: 2006-02-17
Yeah, I think there can be

Yeah, I think there can be a negative stigma with this profit mechanism if not understood completely, but here's where I'd like to make it clear. You, Libervisco, were instrumental in helping me think this mechanism up, and I appreciate it. For everyone else, here's how it works, and I hope I express it much like Libervisco envisioned it....

1. Minor releases will *NOT* be held back and will be made free. There are major releases and minor releases. There's a difference here. Minor releases tweak small things that one could easily argue should have been tweaked before release.

2. Security releases will *NOT* be held back and will be made free.

3. Raging critical bugs that badly require a patch -- these will *NOT* be held back and will be made free.

4. But major changes to the application such as adding a whole new toolbar or new file export mechanism or other major feature -- these *WILL* be held back only for the paying public at least by one release version.

5. If one is willing to wait until two major release versions come out, they can retrieve the last major release version for free.

6. Even the pay version (the latest major release with all updates) is GPL. The added charges are for the cost of my time and wear/tear to redistribute the media, plus the thick manuals and small tech support incident pack which are non-GPL.

And here's what else I've added besides my discussions with Libervisco....

6. This is *NOT* the only profit mechanism. There's others, such as making someone have to physically witness with their own eyes a notice about purchasing the product from the website (can't steal a hardcoded hyperlink and blog it on their site, in other words) before they can click the FREE DOWNLOAD link. They may have to click like 3 links into the site in order to get to that link, and the final link's URL shifts with something unpredictable (so that it cannot be programmatically snatched). This gives ample time to let someone know there's a pay version. And oh yes, there's no popups in this process.

7. Google Ad-Sense or other non-intrusive text-based advertisement medium is going to be necessary in order to hedge financial bets, initially.

8. I can charge for manuals. Of course, it's bad form to charge for end user manuals in my opinion, so I'll charge for things like advanced hosting questions + programmer SDK type manuals, which take a very long time to compose when done properly.

9. I can charge for onsite or offsite consulting.

10. I can charge for training.

11. I can charge for tech support incident packs and access to the very latest knowledgebase (rather than last month's knowledgebase).

12. By building marketshare, I can develop what's called synergy, which could potentially mean I'm an acquisition target, and that could potentially mean huge profit. Just check out JBoss. They got a huge chunk of marketshare and RedHat paid very nicely for it.

tbuitenh's picture
Offline
Joined: 2005-12-21
I see a few problems with

I see a few problems with your "pay for the newest version" approach:

If a community forms around your software, it is very likely it will make changes to the free version, not the paid version. If you like those changes, you might sometimes have trouble porting them to your paid version, which could eventually lead to a fork, kicking you out of your own project.

The other problem may or may not occur, depending on what kind of software it is. If it does anything important, many users will want to use a slightly outdated version, to let all the possible problems in new versions happen to other people instead of them. And the slightly outdated version is the free one!

If I understand correctly, then saying it in a not so nice way, your model is the proprietary one, with the added gimmick of giving old versions to charity. I think there is nothing ethically wrong with it, but that way you won't get much help from other developers. If your project stays a one man show, many users won't be willing to use it for anything critical: if there's only one guy who knows the code very well, and that one guy gets hit by a car, that's bad.

supermike's picture
Offline
Joined: 2006-02-17
tbuitenh: Keep the thoughts

tbuitenh: Keep the thoughts coming. I'm still dreaming, working out the kinks here on this.

a thing's picture
Offline
Joined: 2005-12-20
pay for features

Do that weighted-voting-for-a-bug thing that http://bugs.kde.org/ does, except voting points for feature requests cost money.

supermike's picture
Offline
Joined: 2006-02-17
On the 'one man show'

On the 'one man show' nature of my current CRM project. It's like this. If I brought in another developer right now, with as slow as I've been able to find free time to work on it, then they would be quite frustrated, waiting on me. I keep getting in this "just two more months" mode. So building Cathedral software, supposedly, is bad, but sometimes you just have to do that to project a vision, a genius, that others cannot see until you build it your way. Then, when it's released for the first time, and people say, "Wow, that's a whole paradigm shift on how I would have thought to have done it -- what a genius!" then that's the time to get other developers to help you extend this vision. Of course, not all software design goes that path -- I've already started another, separate project that's completely grassroots in Bazaar mode (versus Cathedral mode) on SourceForge.net and we're growing it from there.

libervisco's picture
Offline
Joined: 2006-05-04
Okay, I'm catching up to

Okay, I'm catching up to this..

TBuitenh has some good points there. It's hard to keep the separation between the paid for version and the free version and still have significant community contributions. It pretty much comes down to choosing between the benefits of community input or the benefits of the paid version. In the latter case you do all the development alone and the community is less participatory, merely suggesting ideas and issuing feature requests hoping for those to show up in the new releases.

And yes, there's nothing really wrong with that. The question is just what will work better for your business.

I think a_thing also has a nice idea. If I understood correctly, it would involve selling voting points for specific feature requests. The feature requests for which you sell most voting points are implemented. It's sort of a "vote with your wallet" model I suppose where the community pays for features they badly want.

a thing's picture
Offline
Joined: 2005-12-20
better than what I thought
libervisco wrote:

If I understood correctly, it would involve selling voting points for specific feature requests.

That's not what I originally had in mind, but it's better. What I originally thought was that you'd pay for votes, then decide where to spend them. Your way eliminated the possibility of people voting for something then withdrawing at the last minute so they don't lose their money, but the votes still brought the value of the feature request up while they were there.

Offline
Joined: 2006-03-28
I think there might be a little conflict
libervisco wrote:

TBuitenh has some good points there. It's hard to keep the separation between the paid for version and the free version and still have significant community contributions. It pretty much comes down to choosing between the benefits of community input or the benefits of the paid version. In the latter case you do all the development alone and the community is less participatory, merely suggesting ideas and issuing feature requests hoping for those to show up in the new releases.

And yes, there's nothing really wrong with that. The question is just what will work better for your business.

If I get this correctly I see a little problem here. One version exclusively developed by you (the commercial version ) and a version with help of the community might not be such a good idea. In terms of speed of implementation you can't keep up with a well maintained community-project, which will result in the free community-edition outshining the commercial version.

libervisco's picture
Offline
Joined: 2006-05-04
Well, because of that it is

Well, because of that it is probably better to go all the way and let the community have and improve all the version. Either that or go all the way in *not* releasing a free version, that is, charge for every download. But even then, someone in the community may pay to get it and then since it's under the GPL fork it off into their own project.

It looks like there are more winning possibilities in going free all the way. Then you can gather the community around without any constraints and offer services around your application. One of those services may be those voting points for feature requests. I imagine this is something the community would not mind.

a thing's picture
Offline
Joined: 2005-12-20
Cygnus

Take a look at happened with a buisness model similar to supermike's original plan.

libervisco's picture
Offline
Joined: 2006-05-04
<