Can Proprietary Language Teams Succeed By Going Open Source? 136
JerkyBoy writes "RunRev maintains the proprietary LiveCode programming environment. Those familiar with HyperCard on the Mac would feel quite at home using the environment to produce simple applications, and possibly more, although the programming language it incorporates has a few significant shortcomings (e.g., true object orientation). But it is a very versatile environment, currently claiming support for Windows, Mac, Linux, iOS, Android, and server-side scripting. For us NOOBs who could never find the time to learn C++ and something like the wxWidgets or QT toolkits, it seems like a pretty good deal. Recently RunRev has done something interesting, however, and that is to create a Kickstarter campaign to move the environment to open source (~500K lines of code, ~700 files). The way that they describe it, it sounds like there will be a commercial version and an open-source version of the environment (hopefully not cripple-ware), and they are asking for money to do this. But I want to know: what are their chances of success with this model? How in the world can they make enough money to maintain their programmers and overhead while giving the environment away? In other words, if a company like RunRev announces that they are moving to an open-source model, should you become more interested or less interested in their product?"
Re:Yes. (Score:5, Insightful)
Microsoft's wide portfolio of products may allow a little cross-subsidisation (mild understatement), which is not really an option for a one-product firm as described in this story.
Also the Express editions might be considered loss-leaders: you start with the basics and eventually you need the full-blown paid product. It doesn't seem like this firm is differentiating its offerings in such a way.
Re:open source (Score:2, Insightful)
Except Novell. Er.. and Sun. And SGI... Google is struggling to keep control over Android and put the cork back in the bottle. I would say that open source is fine if you don't want to commercialize the product in a heavy way.
Perhaps it's the other way around (Score:4, Insightful)
Perhaps they are going OSS because they realized their product is simply not going to be successful closed source. The fact of the matter there are many many OSS options which already have wide adoption, and real developers will likely prefer these solutions over any closed source one. Tehre is also the fact that a non OSS platform will simply be dropped at some point and updates will stop - at which point you'll be screwed.
Poster pointed out one of these examples: hypercard, but I'd just like to point out that we had started developing an app on AIR only to have them drop cross platform (Linux specifically) support 2 months into our development. It was a job for a client, and we had to spend a few extra weeks porting it to Java. Since that time we have refused any proprietary platforms, which we didn't like in the first place but we now view as a direct risk. We don't even look at non OSS for our development, environments and libraries included.
Re:Shortcoming (Score:5, Insightful)
Object orientation is a tool, unfortunately most programming languages treat it as if was a religion.
what a waste of money (Score:5, Insightful)
Paying to get something nice open sourced is a good thing.
Paying to have a stripped down IDE and language open sourced... not so much.
If you want to learn programming, use JavaScript, Python, or Ruby; they're free, easy-to-use, and they scale up to real problems.
Re:Too many languages - insanity (Score:2, Insightful)
Because you haven't thought it through because you are focused on the red herring that enforced whitespace is.
Everyone formats their code, therefore enforcing it buys nothing, but a few less {}.
There are heavy costs such as Python's gimped lambda. The reason it is pretty much worthless is because of the enforced whitespace, the lesser reason is because Python doesn't follow the everything is an expression design like proper languages.
It also makes debugging harder, because sometimes the best way to debug something is to throw in a few quick throw away print lines. Can't easily do that with enforced whitespace.
The last is simply that if you move files from one system to another the formatting can get borked, which absolutely sucks.
I have seen 1000 line Python files lose their indentation making it worthless.
So, for the small value of enforcing what everyone does anyway, the language is less powerful, and less capable of recovering itself if something in the file gets corrupted.