Ask Slashdot: Viable Open Source Models For Early Startups?

New submitter rchoetzlein writes "I am a software developer working independently for five years on various projects, and preparing to go public with my first product. Everyone is telling me I should make it open source. I would love to, but I just don't see how an early startup can afford to become profitable on service alone. My projects are no longer small-scale hobbies, they are large frameworks, and I need to make a living. Any ideas on business models that would allow me to open source while guaranteeing I can feed myself?"

Comments

Re:If you think open source is not the way to go..

[Ihmhi]

If you think open source is not the way to go, then why bother asking slashdot? Seriously? You won't get the answers you're looking for here.

Yes he will.

The way I read it, ethically he thinks open source might be the right thing. Practically, it might not be a reality. He's fishing for examples of unconventional open-source money generating techniques.

Sunset

[shentino]

Try sunsetting your proprietaryness.

Have your product be proprietary for a finite period of time, and once a particular version is EOL'ed or otherwise ceases to be commercially viable, open source it and let the public go nuts over it.

You only need to keep your leading edge keen in the market.

Re:If you think open source is not the way to go..

[Acapulco]

I believe parent has nailed it.

Ethically you want to do what is closest to your heart if you will, but unfortunately you need to eat, and usually this involves doing the opposite of ethical (or at least far from what the ideal-ethics tell you)

So I propose this. How about you release version 1.0 and 1.5 for example (or 1.0 and 2.0 or something) as regular closed-source software, and then when the next version comes out, you release the previous one as open source (e.g. release 1.0 and 2.0 for pay, when you release 3.0 for licensing you release at the same time v1.0 as open source)

Of course this would mean that you would have to have a road map for what you plan to introduce to your software along the years, so its easier to establish which version is to be safely released as open source without it hurting your paying customers. So, I think you would have to make significant changes and upgrades along the life of your software so it stays competitive and entices costumers to keep upgrading instead of waiting for the open source version, or in the case where the user doesn't really need the "greatest and latest" he could fallback to v1.0.

Disclaimer: I haven't actually put to work something like this, and actually this is an idea I believe I read here on Slashdot as it is, but I think, if not directly useful to you, could give you an idea of a "hybrid" approach, where certain functionality is still closed source as it requires the most of your time (so it costs more) but you still have the open version to maybe encourage some devs to take interest in this framework, or at least show your clientele that you really care about open source however economically infeasible it is for you.

I would say its on the same line of thought as "pay-what-you-think-its-worth" for games like World of Goo and such. You could effectively buy it for 1 dollar, but like me, a lot of people thought it was really nice of them to do this and since I actually enjoyed the game a lot, I payed like 15 or 20 USD (the original price). And even use that as a marketing tool.

Just my 2 bytes...I mean cents.