CrippleWare, World of Open Source

« previous entry | next entry »
May. 5th, 2008 | 12:03 pm

Ever since I did my original post on Crippleware I have been getting a lot of feedback from individuals about how the intersection of open source works with closed source extensions.

Open Source that is not crippleware but allows for third party extensions allows for the following:

  • Open and documented APIs with stable interfaces.
  • The ability to compile or load the software without "secret sauces".
  • The consumer right to always have access to the data they have entered.

    The first two really deal with the issue of whether or not the vendor has created a "level playing field". Third party vendors who write modules expect an even handedness when dealing with APIs.

    This means that there are no special tools required that cannot be obtained by a third party. No special, aka undocumented, interfaces that modify the API or service interfaces that the modules need to make use of.

    No third party vendor has a right to create a closed source module, the GPL by its nature creates a cost that the third party must open source.

    Quid Pro Quo works in favor of open source. If you write an extension to an open source project you play by the rules of the project's license. This means a closed source module should expect, or at least assume, to have to pay for the right to link. With exceptions to this being granted by the project. Open source adherence modules should expect that they are free to distribute their work, but realize the vendor of the original project may also distribute the module as well.

    In the world of the BSD license anyone is free to extend and distribute. There is nothing inherent in the concept of open source that does not allow for proprietary extensions, it is the nature of the open source license chosen for the project which defines what is acceptable for the licensing of third party modules. Behavior which creates open source software which is crippleware comes from the author and their intent.

    What do both closed source and open source modules share in common? A right to an Open API that has some level of definition and stability.

    If the vendor changes the interface without notice with deliberate intent toward third party modules this is a behavior of crippleware.

    Any project should be communicating API changes, this is a part of being a good steward of an organic open source model.

    As an example of deliberate intent would be if a vendor created a substandard behavior via the open service API and chooses to hold back a more competitive interface for themselves. This is a behavior of crippleware.

    Interfaces must be open and accessible in order to avoid being crippleware.

    A consumer should expect to always be able to extract their data from an open source project in a common manner. Whether this is by printing or exporting, data portability is at the essence of the freedom open source is to provide.

    Telling the user to "write it themselves" is unacceptable behavior. Users have a right to data portability, and I personally think this goes beyond the question of open source.

    In an open source world you will not win a ribbon from anyone in the community for merely having an open source license. If you cripple the very nature of open, you should not be surprised when the community is not impressed.

    At the end of the day it is about having appropriate table manners.
  • Link | Leave a comment | Share

    Comments {8}

    awfief

    (no subject)

    from: awfief
    date: May. 6th, 2008 12:57 am (UTC)
    Link

    How many open source projects follow this completely?

    For instance, I'd consider InnoDB to be crippleware because there's no hot backup that's open. Sure, I can use mysqldump to retrieve my data, or a disk snapshot, or copy the file, but:

    1) if it's not internally consistent, it's not an accurate representation of my data.
    2) InnoDB Hot Backup is closed-source, for-pay.

    The important thing in open source, as in many areas, is that you obey the spirit, not the letter, of the agreement. Sure, many things are technically open source, but not all of the value comes from being able to read and/or write the source -- you bring up excellent points in that it's important to keep the *data* open and accessible, not just the code.

    Anyone who's ever found an old floppy disk with a file format they can no longer read knows this problem. If only they'd been able to export to a reasonable file format.

    Hell, even Microsoft Office can export to text files, and HTML files. In some cases I'd rather have closed source but easily (and complete) accessibility to my data.

    Reply | Thread

    Brian "Krow" Aker

    (no subject)

    from: krow
    date: May. 6th, 2008 07:37 am (UTC)
    Link

    How many keep stable API? Almost none. Most do an ok job of it, but no one is stellar at it.

    I think Innodb is complete. Over backup do they skate the line? Probably. I think it would be a testament to their integrity only if they had actual competition, and I do not believe that this is likely (its open source... so one never knows).

    Today though there is mysqldump and it can remove the data... so I don't believe there is any vendor lock in to Innodb.

    Reply | Parent | Thread

    (no subject)

    from: axehind
    date: May. 6th, 2008 04:14 pm (UTC)
    Link

    We have a company that makes a opensource product. Then makes a closed source product that interacts with the opensource product. How does that make the opensource product crippleware? InnoDB is the main product, it and it's API's are all opensource. The hotbackup is a addon.

    Reply | Parent | Thread

    awfief

    (no subject)

    from: awfief
    date: May. 6th, 2008 05:04 pm (UTC)
    Link

    Yes, but I can't get my data out without buying a product. I can use mysqldump, sure, but that's not a consistent online backup, and the nature of databases these days demands that a backup be consistent and online.

    If it's not consistent, it's not an accurate snapshot of the data. It may as well be gobbledygook; if it's not consistent, it's not my data.

    Similarly, if I have to break the database functionality to get the data out (ie, the backup is not online) then it's hardly usable. To me, this is akin to the "write it yourself" mentality -- "either you have to break the database's functionality XOR you have to live with inconsistent data".

    The *only* solution is a closed-source solution. mysqldump is *not* a solution for an in-use database.

    Reply | Parent | Thread

    (no subject)

    from: axehind
    date: May. 6th, 2008 05:46 pm (UTC)
    Link

    The "write it yourself" mentality you/I see a lot of in open source. I think this is great in some ways because it gives you the option to do that and you have the code to be able to do that.

    I understand what your saying about the backup. I guess it's like putting out a product and kinda limiting the usability of it.

    Reply | Parent | Thread

    David Phillips

    (no subject)

    from: davidphillips
    date: May. 6th, 2008 11:19 pm (UTC)
    Link

    Disk snapshots provide online, consistent backups. Think of a disk snapshot like pulling the plug on the server. If the data on disk wasn't always consistent then the database could not recover.

    The downside to snapshots is that the snapshot is not "clean" -- the database must run it's internal recovery procedure, same as if you pulled the plug. (I don't know how long recovery takes with typical InnoDB setups. It might not be an issue.)

    Reply | Parent | Thread

    Brian "Krow" Aker

    (no subject)

    from: krow
    date: May. 6th, 2008 11:23 pm (UTC)
    Link

    I've never used the Innodb hotbackup tool. I use LVM snapshots, and mercurial based dumps.

    Reply | Parent | Thread

    Wondering...!!!

    from: weblogzz.blogspot.com
    date: Dec. 28th, 2008 08:06 am (UTC)
    Link

    I wonder how you came up the top for file recovery.I ended up here searching for it.Anyway here is the right one.
    File recovery tech blog (http://weblogzz.blogspot.com/2008/06/oops-i-deleted-file-file-recovery.html)

    Reply | Thread