Forgot your password?
Open Source

Can Proprietary Language Teams Succeed By Going Open Source? 136

Posted by Soulskill
from the reply-hazy-ask-again dept.
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?"
This discussion has been archived. No new comments can be posted.

Can Proprietary Language Teams Succeed By Going Open Source?

Comments Filter:
  • Of course it can work. Even Microsoft does something similar with its express editions.

    • Re:Yes. (Score:5, Insightful)

      by ratbag (65209) on Sunday February 03, 2013 @06:47AM (#42776665)

      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.

      • But this sounds like something kind of scummy.

        RunRev already has a coded product that they have been selling for years.

        This sounds like a "sales are bad, so lets see if we can sell out and get a wack of cash from suckers in exchange for releasing part of what we've done as open source while still keeping the important bits for us to sell"

    • Re: (Score:3, Informative)

      by fortyfoxes (2831679)
      It's pretty close to the Blender story - where a closed source but active community decided to open up the source code in order to grow the community. See "3D software Blender's "community buy out" in 2002" - []. I was at the launch event, and they faced many of the same code issues that the LiveCode community now face - a large amount of legacy code written in a way which was difficult to open source. Blender is now the preeminent open source soft
  • I haven't seen any single case where moving to open source was bad for the mover.
    • Re: (Score:2, Insightful)

      by Anonymous Coward

      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.

      • by RDW (41497)

        It looks to me like they'll be dual licensing. GPL3 is mentioned on the Kickstarter page, which presumably includes the deployed runtime libraries, so anything built with this version must also be FOSS. Anyone who wants to build a proprietary application will have to buy the commercial version. This is probably a good move for them. Although LiveCode pitched as an easy to use RAD, the current pricing is too high for casual developers: []

        A GPL edition will kill their education sales,

      • 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.

        Novell had its business model removed as Windows absorbed Networking [much like they are doing with stream now], and after getting involved with Linux took a bribe from Microsoft which like all dealing with Microsoft ended badly. Sun and SGI just fell to Better Value Microsoft PC's, and bad management [overspending].

        Oddly Googles Android is a success story; set to overtake Windows this year. In reality only Linux is truly open source with its slightly amended GPL2 License, the rest is Apache which is why Go

        • In reality only Linux is truly open source with its slightly amended GPL2 License.

          I don't remember ever reading anything about it being anything but a 100% GPL2 license. Do you have a reference to this?

          • by lingon (559576)

            Uhm yes, the license text itself? Just diff COPYING in the kernel tree [] with the one available at []. Honestly, it's not that difficult.

            Anyway, since you were to lazy to do it, the difference is this added preamble (sans some layout changes):

            NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free

  • the programming language it incorporates has a few significant shortcomings (e.g., true object orientation)

    That's the first time I've encountered someone citing true object orientation as a significant shortcoming.

    • Re:Shortcoming (Score:5, Interesting)

      by StripedCow (776465) on Sunday February 03, 2013 @06:48AM (#42776669)

      Indeed. For example, interestingly, the standard template library (STL) used in many C++ projects is actually a move away from object orientation.

      Anyway, I just had a peek at some sample LiveCode source, and noticed that sometimes it approaches human language. For example:

      delete the last char of tFilesWithPaths

      So, perhaps LiveCode is a move back towards the COBOL days?

      • So, perhaps LiveCode is a move back towards the COBOL days?

        I had wondered what all those guys had been up to since 2000 - now I know!

      • Yes - interestingly buried away in the KickStarter is the description of an "Open Language" feature. This feature is particularly interesting with regard to the ease of creation of domain specific languages. In many ways the object oriented nature of much of the code base is hidden behind a language and conceptual model that allows a more intuitive use of object oriented concepts, and wraps these in a DSL. Opening up the source code will allow us all to create truly natural DSL for a whole range of open sou
        • There's already people discussing implementing it in french. I think it would be pretty awesome to have this english like language suddenly become just natural language coding!
          • Re: (Score:3, Interesting)

            by Anonymous Coward

            Nothing better than writing "Add one to number of gadgets, storing result as number of gadgets." instead of "nGadgets = nGadgets + 1;" or even "nGadgets++;"

            If you're so inclined, COBOL is over there [], and Inform7 is over there [] (and it's pretty interesting in its own way).

            Seriously, syntax is never the problem, logic and the need to explain every step is the problem.

            • by Nerdfest (867930)

              I very much disagree. "gadgets++" has about the right information density. COBOL is way too verbose. It takes too much code to do something, and too much reading to figure out what's being done. The term "COBOL finders" exists for a reason. Making the language closer to English is not going to solve the problem most people have in writing software. Their problem is being able to organize their thoughts and apply them in a logical way. In many cases adding verbosity makes it harder.

              • I completely agree that verbosity should be avoided, and so should the use of special characters.
                Syntax that needs detailed comments is also not very good.

                I much prefer to write

                if x<>0 and y/x<z then exit repeat


                if ( (x!=0) && (y/x<z) ) { break; };

                The first line looks cleaner to me: fewer special characters.
                Note also that the division of y by x will not be tried because LiveCode's "and" operator is specified to skip if its first operand is already false. Many languages fail to te

              • by jbolden (176878)

                The advantage is not so much in writing but rather in learning to write. The more natural the syntax the less time it takes to get semi proficient in the language. Obviously "Add one to number of gadgets, storing result as number of gadgets" is much easier to understand. The code explains itself. Also it doesn't tend to lend itself to combinations. nGadgets++ tends to get combined with other statements since it is so short. Overtime and very quickly people start to like more compressed syntax but for

              • by tehcyder (746570)

                Making the language closer to English is not going to solve the problem most people have in writing software.

                You're speaking as a competent programmer, not a novice. Verbosity is not a problem to someone who has only read English and not code before. Any speed penalty is more than compensated for by the fact that they can produce programmes at all. This is a language to learn with, and therefore should be as newbie-friendly as possible.

                Otherwise you might as well say to children and non-programmers "just go and learn Assembly, then come back to us when you can program properly". Hint: very few will.

      • answer error "This is not COBOL" with "It sure isn't" or "Meh"
      • by gtall (79522)

        That's because their language was modeled on Hypertalk which was Hypercard's language. In fact, they advertize that their app will read Hypercard stacks. Their application are essentially stacks but updated to use a more modern architecture.

      • I like the phrase "move back".

        COBOL is from 1958 or so, around the same time as FORTRAN and I think after Algol. It is quite a while ago, but do not forget that the syntax of php, javascript, C++ and the like dates back all the way to C, 1969! The major influence on C was the slowness of the teletype equipment on which it had to be typed in. Why still use syntax from those days?

        I started writing code and designing programming languages around 1970. Coming across Hypertalk and later LiveCode was simply a

      • Hypercard [] on the Macintosh SE30 using Macintosh operating system 6 or 7 could be programmed in the same "almost natural language way":
        go to the last card of this stack
        get the last word of the first line
        put it on the last line

        Note the use of the it variable reference to what was last got by a get command. Cool, eh, and almost twenty years ago...

    • I've been working with LiveCode for over 10 years and develop third party addons for the platform. I don't consider the lack of object orientation to be a big issue although I would like to be able to set a behavior script on a behavior script. I won't say there aren't shortcomings to the platform. One of the biggest is trying to use a VCS with the binary file format. I'm working on an open source three way merge driver for that. I'm looking forward to getting under the hood and sending my first pull reques
    • Re:Shortcoming (Score:5, Insightful)

      by Alomex (148003) on Sunday February 03, 2013 @08:46AM (#42776969) Homepage

      Object orientation is a tool, unfortunately most programming languages treat it as if was a religion.

      • by Kjella (173770)

        It's not the only form of programming, but it's a way of organizing the whole software and non-OOP tends to break that which is why they don't mix well. When I program in Qt pretty much everything is an object, objects have child objects and all the state, all the data is placed in member variables. It is fairly similar to a file tree, directories have subdirectories and files. Delete a file and it's cleaned up, delete a whole directory and it goes away, always and without exception no matter how much I ref

  • by Anonymous Coward

    All the money in programming languages is in books that must be updated every 2 years and training.
    Just ask the Ruby on Rails guys.

    They change the solution completely every 2 years, so that any old documentation is a liability. i've bought and thrown out 3 sets of Rails books over the years because the implementation details changed so much with every major release.

    That is where all the money is in computer languages.

    • by ratbag (65209)

      Get off the treadmill :) Whilst I do have some "current" Rails books (notably The Rails 3 Way), I've stopped getting new editions of the Pickaxe or Agile WDR books. RailsCasts and good old fashioned studying the docs or picking through Stack Overflow have replaced purchasing books on Rails.

      And the solution has hardly changed "completely" every two years. You'd still recognise Rails 1 code if you saw it today.

      I limit my book purchases now to well-regarded overviews of new technologies, published before the f

      • by murdocj (543661)

        I came into Rails recently (a year ago) but I'd agree with GP that the turnover in Rails is pretty amazing (& disturbing). Just in the little time I've been in the Rails world I've seem methods move from being "the Rails way" to being "deprecated". The result is that in general there really isn't documentation per se for Rails... it's Googling Stack Overflow and sorting thru the results to find the most plausible answer.

  • by Kagetsuki (1620613) on Sunday February 03, 2013 @07:05AM (#42776709)

    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.

    • LiveCode has been around for a very long time now and at least one high profile user in NASA.

      It originally started as MetaCard back in the 90's having first heard about them after receiving an offer to create a game using the language for free (it was around $1,500 AU) when I was 15, I had a fairly popular website devoted to my hypercard games and was looking for a new language to learn and this one was just like Hypercard but in colour!!

      Fast forward a few years and they were bought out by Runtime Rev
  • by drolli (522659) on Sunday February 03, 2013 @08:02AM (#42776861) Journal

    I dont consider *new* languages for which there is no open source implementation of the core language available. This is not because i dont like to pay but because in the case of small languages/domain specific companies you never know ehen they go belly up or are bought and what happens then.

  • by mwvdlee (775178) on Sunday February 03, 2013 @08:21AM (#42776901) Homepage

    From kickstarter campaign:

    We have selected the GPL because it encourages sharing by ensuring that any applications created with it are also open.

    This isn't true for any current compiler available under GPL, why would it be true for thier compiler?

    • We have selected the GPL because it encourages sharing by ensuring that any applications created with it are also open.

      This isn't true for any current compiler available under GPL, why would it be true for thier compiler?

      It *is* true for all current compilers in major use. If you look at your favourite compiler's license, you'll see an *explicit* exception that exempts compiled programs from being covered by the compiler's copyright claims. The Microsoft compilers do it, even GCC does it [].

      • by Anonymous Coward

        You're mixing up compilers and compiler runtime libraries. What applies to one doesn't apply to the other.

        Applications compiled with a particular compiler do not inherently fall under the copyright license which covers that compiler's implementation, because no copying of the compiler code is involved. However, it is quite common for compilers to provide libraries with which the code generated for the application is linked, and static linking to such libraries would in general propagate the license carrie

        • Applications compiled with a particular compiler do not inherently fall under the copyright license which covers that compiler's implementation, because no copying of the compiler code is involved.

          Except for bundled include files, which clearly fall under the compiler vendor's copyright.

          For languages such as C, it is impossible to write nontrivial programs without making use of include files. In special cases, such as with the standard system libraries, it may be legal to rewrite them from scratch

    • Possibly the core libraries are GPL. So any linkage becomes a derivate work.

      By contrast, gcc is GPL but the the gnu libc contains a linking exception so that the resulting binary is exempt. Similarly with openjdk.

    • by Kjella (173770)

      This isn't true for any current compiler available under GPL, why would it be true for thier compiler?

      Because it's been explicitly exempted. When you write something that's not directly 1:1 mapped to an machine instruction, the compiler will either a) link you with a dynamic library with the low level code, b) provide a static library with the the low level code or c) inline the low-level code directly into your code. That low level code is copyrighted and all of the above will make your code a derived work of that low-level code. I don't know if anyone has tried the "I compiled it against my own library st

      • by jbolden (176878)

        Copyright law has been clear for a long time. If X is designed in such a way so that it only works with a pre-existing Y then X is a derived work of Y. That's not even controversial. Yes it has been tried, and the results in case law are crystal clear.

  • by stenvar (2789879) on Sunday February 03, 2013 @08:52AM (#42776991)

    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.

  • by rumith (983060) on Sunday February 03, 2013 @08:58AM (#42777003)
    How do you define success? Your open source language project doesn't have to be good to be popular (example: PHP), but it must have a certain audience that finds it appealing. Open sourcing the project is not a magic bullet; if nobody likes your product, you're out of luck. However, if you have carefully studied your audience and believe that such a step will remove the main roadblock for adoption for a large number of potential users, this is definitely worth doing.
    • by Anonymous Coward

      PHP was just glorified SSI when it started. It was the only way to go back then. PHP didn't gain traction because it was good or appealing, it gained traction the same way as MSDOS.

      I must say I love parts of PHP, especially the hash arrays.

      • by Anonymous Coward

        Yeah, mixing two orthogonal data structures into one messy, inconsistent data structure is a great idea!

        Don't get me wrong, I love PHP. It helps me avoid hiring and working with shit programmers. If they have ever used PHP by choice, or hell even by force(good programmers don't need to accept shit work from shit companies and any company that makes use of PHP is shit) is an instant no hire.

  • No. If they want to extend buy-in by releasing a limited open source version that is their prerogative but 1) it is not worth paying money for since it is a marketing expense of their company and 2) I doubt it will work. Why bother going to a closed model? Two salient experiences:
    Salesforce. Has a very strong product with huge interest. A managed, growing language and set of libraries. Drawbacks are it must run on their server, and many undocumented things. If you have a reason to use Salesforce (and many c

    • by Anonymous Coward

      This is not a lite version. The entire platform is being opened up, it is the same source base in the open and closed version. Students, teachers, in-house developers and those creating open source software can all use the entire feature set for free. The only thing you can't do is create closed source apps with the open version.

  • The question is: can they survive without going (partly) Open Source? The target audience for these kind of pseudo-programming environments is pretty small, and there's no major platform without an free SDK. The learning curve for cross-platform programming using Java or QT is not that big, either. So I think it's a good move to start giving some of it away to attract more paying customers.
  • by Anonymous Coward

    Sort of Worked for DigitalMars D Language.... but the community popularity fadded out some how, maybe because of the non compatible changes of the second generation of the language definition

  • It amazes how quickly things move off topic. The "it's not as good as x" or "only real men program in x" folks really feel a need to hop in. I fall into the category of programmer that makes his extra money programming, the day job pays the rent. I also use the tool, or language, that gets me where I want to be with the least amount of hassle. The world really is big enough for a number of languages.

    LiveCode has its place. It is fast and convenient to develop in. The primary issue is its distance
  • I don't like programing in modern languages because their not a lot of fun. Python Ruby, etc... Live code is both approachable, and fun. Now fun is a vary subjective thing, but I think Live Code would come out hight on the fun factor
  • if you want to be successful as a language, you need to go open source.

  • I have been in charge of the development of an OSS (GPL) language - albeit very different from the one mentioned in the OP - called Obyx (cf. [] ). Our motivation for OSS was so that clients would feel less bound to a proprietary model. We use (and love to use) Obyx for the development and deployment of dynamic web services. The actual effect of changing the license model (much of our remaining software is proprietary and closed) has been nominal - it has meant that we have shifted more

    • I think the motivation is primarily uptake but there's going to be some interesting side effects. For example there are a number of people very keen to see this on the Raspberry Pi which will require an arm Linux engine as currently we only have x86. As the core goal of the Raspberry Pi is programming education I think LiveCode will fit nicely between Scratch and Python. The language is very much like the scratch language without having to drag blocks around.

      I am starting to wonder if pitching the kickstart

It's later than you think, the joint Russian-American space mission has already begun.