Kitely Market reports high exports growth, new mobile site

The exportable content on the Kitely Market grew ten times faster than non-exportables over the past month, continuing a trend that began late last summer.

The market added 245 new exportable items, compared to 23 non-exportable ones, for a new total of 7,950 different variations of 3,898 products. A single Kitely Market product can be sold in multiple variations, such as different colors, different prices, and whether or not it’s exportable to other grids.

According to the latest Hypergrid Business numbers, there are currently more than 18,900 active users on the 225 hypergrid-enabled grids, all of whom except Littlefield are potential customers when Kitely merchants set their content to “exportable.” In addition, some otherwise closed grids have also enabled Kitely Market deliveries. (Instructions here.)

By comparison, although Kitely is a top-ten grid by traffic, it only has 1,109 active users, according to the latest stats. And the hypergrid as a whole is growing significantly faster than the population of the closed grids.

Active users on the hypergrid-enabled grids and closed grids. (Hypergrid Business data.)

Active users on the hypergrid-enabled grids and closed grids. (Hypergrid Business data.)

Since crooks aren’t likely to pay for a product before stealing it, Kitely Market merchants have been finding that selling content to the hypergrid gives them access to a large new user base, including schools, non-profits, and companies running private grids. Plus, with the exception of scripted and rigged content, it does not increase the risk of content being stolen, while simultaneously reducing the demand for that stolen content.

As you can see from the graph below, after an initial jump in early 2014 when Kitely Market first enabled exports, growth in exportable content — the green line — leveled off for a while in the summer as merchants waited to see what the results would be. As positive results started coming in from merchants such as Ozwell Wayfarer — who reported multiple hypergrid customers spending $100 to $200 in a single shopping trip — more merchants embraced the hypergrid.

For example, Heart Botanicals offers 20 different items on the Kitely Market — all of which are available for delivery to other grids.

Exportable and non-exportable content on the Kitely Market. (Kitely data.)

Exportable and non-exportable content on the Kitely Market. (Kitely data.)

Meanwhile, Kitely has continued to improve outreach and usability, with a new mobile-friendly Web redesign and advertising campaign.

Ilan Tochner

Ilan Tochner

“We started the Kitely Market ad campaign in SLUniverse and Hypergrid Business and have seen a drastic increase in sales activity in our marketplace as a result,” Kitely CEO Ilan Tochner told Hypergrid Business.

He did not disclose the company’s sales numbers.

The new Kitely Market Web app is a mobile-optimized website that makes it easier for Kitely Market customers to shop from their phones or tablets.

(Image courtesy Kitely.)

(Image courtesy Kitely.)

“The goal is to enable people to benefit from having a Kitely Market ‘app’ without having to install it from an app store,” Tochner said, adding that app stores take a significant cut of in-app purchases, increasing costs for merchants and raising prices for customers. “Being able to sidestep that additional cost can help keep virtual items affordable.”

In other news, Kitely has enabled the uploading of standard OpenSim varregion OAR files into Kitely and having them automatically converted to their Advanced Megaregions format.

Varregions typically have fewer problems than megaregions, but require that users have the latest Firestorm or Singularity viewers. Kitely’s Advanced Megaregions combine the best of both.

Both varregions and megaregions allow multiple regions to be combined into one large region, with no border crossings. This allows vehicles and people to travel through larger areas without scripting problems or “rubberbanding” at region boundaries.

maria@hypergridbusiness.com'

Maria Korolov

Maria Korolov is editor and publisher of Hypergrid Business. She has been a journalist for more than twenty years and has worked for the Chicago Tribune, Reuters, and Computerworld and has reported from over a dozen countries, including Russia and China.

  • Geir Nøklebye

    I tested uploading to the HIFI Marketplace, but so far the experience was underwhelming. The mesh had to be exported to FBX, then uploaded to a location you were able to create. Once the item was rezzed, it had to be saved in another intermediate format back to your local machine and only then could it be uploaded to the marketplace.

    As far as I can find out there is no way to ungroup a grouped object saved to FBX once uploaded to HIFI, so each component must presumably be uploaded as individual items and re-assembled.

    This is of course only an alpha version so I take it things will change. However, it the final system resembles this procedure, content providers shall be hard pressed to convert their models unless there is a sizable market. Serving items from Kitely may also be a challenge given the double format conversion.

    • Please rest assured that once we enable delivery from Kitely Market to High Fidelity you won’t have to deal with High Fidelity Marketplace’s convoluted listing procedure.

      • Geir Nøklebye

        It was very convoluted :-))

        Perhaps you can outline how this “magic” is supposed to happen without the creator overseeing and approving the final product delivered to HIFI?

        • Nope, that will be a surprise 🙂

          • Geir Nøklebye

            Content creators usually don’t like surprises like that. We usually want to have tight control over product, quality, pricing and which market the products go into. 🙂

            EDIT: We also like to know way upfront what formats we need to support before we enter a (new) market.

          • The surprise won’t be to the content creator when they list new items. I meant I won’t specify how our simplified procedure will work at this time. If High Fidelity wishes to implement something simplified they’ll have to figure out how to do it themselves or wait for us to roll out our solution to see what we did.

          • Geir Nøklebye

            I am not so worried about that, but about format conversions. It is bad enough to have to support another format (FBX) and every conversion does something with the final product.

            This is probably where you want to use NDA at some point to get input on the process before you take the plunge. Since we are still at HIFI alpha, I guess it is a very moving target at the moment.

          • There are file format conversions that are lossless. Not every conversion changes the final product (especially when what is saved is a mesh + textures/materials).

            There is content (like LSL scripts) that won’t be cross platform but there is content that can be be checked in one virtual world platform and be delivered as-is (with automatic scale adjustments, etc.) to other virtual world platforms. Obviously content creators will be provided with ways to test the results on target platforms before they enable people to buy those items in those platforms.

          • One question I have is will there be a way to sell an “OS version” and a “hi-fi version” with different scripting?

            So for example if I sell a house with scripted doors that are fairly easy to change out, will it be possible? I understand that complex things will probably not be possible, but it would seem some way to do this for basic things is needed/desirable, though I imagine tough to implement as it would mean being able to apply the Hi-Fi scripting language while in Opensim.

            But otherwise people will pretty much be limited to selling static props, so i would be interested to hear if your tackling that aspect at all.

          • Not at first but eventually you should be able to have different product variations in the same product listing containing items optimized for different platforms. So, one variation could contain a mesh + LSL script while another could contain the same mesh + JavaScript (e.g. for High Fidelity).

          • Geir Nøklebye

            I think you have to factor in that the creator has the full say on what happens to their creation, and you cannot plan on any auto conversion that the creator does not have 100% control over including which platform to offer the product on. 😉

          • Totally agree there. It should be op-in only. The creator should be able to decide which platforms to sell to.

          • As you mentioned, HiFi is currently Alpha. So I really would not get hung up on the whole FBX thing just yet. In fact I think Philip mentioned at the OSCC that eventually they want to support as many formats as possible. At this point, nearly everything is up in the air and subject to possible change.

            FBX is an industry standard and probably just gave them the widest selection of usable content with minimal time/effort. I would not expect it to stay this way.

            And ultimately, if Kitely can get my builds into HiFi with minimal / no effort from me, I dont really care how they go about it so long as it works.

            Also, while I am totally with you, I dont want to support another format, it should be noted that creators in other 3D marketplaces do sell their wares in a variety of formats. So it is possible that is a trend we could see rise in the future if a marketplace ends up offering the function to sell DAE/FBX/3DS directly.

            If VR becomes mainstream, I imagine places like the SLMP and Kitely Market will become more like Turbosquid and FallingPixel and not vica versa.

          • Geir Nøklebye

            There is a lot of “auto-converted” stuff on Turbosquid, but it has all been generated from the original source and usually the quads are preserved even though the result of often less than desirable. Of course, none of it is scripted or animated although there might be the odd rigged model.

            Mesh uploaded to SL or OpenSim gets triangulated optimized for the SL renderer. If exported elsewhere it might be triangulated again in a different direction to satisfy another renderer so you quadruple your geometry in a very undesirable way over the original.

      • Geir Nøklebye

        I am also a bit curious what would be the advantage of having items listed on the Kitely Marketplace for transfer to HIFI?

        Since they seem to design for the Occulus and such devices, most of the content designed for SL or OpenSim is completely useless there as due to the SL camera angle we exagurate items and rooms in the height dimension (actually also room width not to have the camera dig itself into the walls.) These dimensions look ridiculous seen through a VR device, so everything have to be redesigned for realistic dimensions. The camera angle is also the reason why we end up with very tall avatars in SL and OpenSim.

        Scripting is done in javascript, so everything will have to be rewritten.

        The avatar rigging is completely different so animations will have to be redone.

        The avatar rigging is completely different so all worn, rigged attachments (if supported) must be redone (shoes, clothing, hair, whatnot…)

        As for system clothing (if there is such a thing) and skins, one might be able to convert, but that would presumably be from the crude uv map of the SL avatar, to a higher resolution uv map on the a) standard avatars or to b) custom avatars. So any conversion (if possible) would have to be done on the higher resolution files content creators works on.

        Particle system and lighting is an open question.

        All the above is also applicable to SLv2 which is the reason why LL have said the only thing you can transfer is your identity and money account.

        • Scripts and items depending on particular avatar standards (skeletal system, body proportions, etc.) might not be easily converted as-is to other platforms. But (A) some platforms have configurable skeletal systems and (B) not every product has to be deliverable to every platform and (C) some items may have different variations for delivery to different platforms and (D) there are many marketplace items which don’t contain anything that prevents them from being delivered as-is to multiple platforms.

          The benefit for merchants would be that they will (A) have access to Kitely Market’s much more advanced feature set and (B) Kitely will provide them with a simpler building and listing experience and (C) they will be able to deliver to multiple platforms from a single marketplace, including ones that have different “grids” (the High Fidelity name space is currently managed by High Fidelity the company, that platform will get something like the OpenSim Hypergrid protocol eventually which will make it a lot more distributed and harder to service from High Fidelity’s marketplace).

          Please note that the features High Fidelity stated they want to eventually support are either already implemented in Kitely or have been designed into our system and can take us very little time to complete. We also have additional unique features planned and have several years head start on developing them on High Fidelity’s team. I don’t want to go into details but if you’ve listened to my presentations about Kitely Market you may have noticed some of these advanced features being hinted at.

          • Geir Nøklebye

            In their recommendations they say to upload the FBX source files to a high performance CDN such as amazon, so it looks like each content provider will be responsible for serving up their own content to anyone they meet or who visits their scenes/domains (meaning a very distributed approach.)

            For the marketplace they may actually do a new upload, but it could be just stub files pointing to the originals. It is not very clear at the moment.

            When it comes to avatars their recommendation is to use the avatars from Mixamo which in reality would end up you with a $1500/year subscription for anything but a very basic avatar. They also mention the DAZ avatars, but the license for the gaming version is much higher, and it does not have the resolution of the face mesh required for facial animations. The Mixamo avatar has 21k polys for the head only, which is more than 3x the entire SL avatar. The DAZ gaming avatars are around 12k polys for the entire mesh.

          • A truly distributed approach would be somewhat similar to the Hypergrid where each “grid” controls its own name space (among other things). So, for example, your avatar would be “My [email protected]” and using “My Avatar” without a domain reference would refer to the “grid” the querying avatar belongs to and not the global High Fidelity controlled “grid”. This means that organizations could assign entities (users, places, etc.) a permanent identifier that can be referenced from other “grids” as well without having to pay High Fidelity for reserving that identity in the global name space.

            In a truly distributed architecture High Fidelity, the company, would have a very hard time monetizing the open sourced parts of its code base as anyone could operate a High Fidelity “grid” providing the same virtual world services that High Fidelity does. It would, of course, still enable people to provide various value added service, such as marketplaces, hosting, automation services, etc. but anything open sourced would be commoditized.

          • Geir Nøklebye

            Not sure exactly what their business model is in the long run. I paid $10 for the xmir domain for a year. 🙂 It currently does not run all the time, but that may gradually change as we get more meat to the bone.

          • Soul Train

            How do you know they are not running two parallel programs with one being proprietary while the other open sourced?

          • Geir Nøklebye

            I am pretty sure they do where one of the programs will end up as SecondLife v2. If you analyze Ebbe Linden’s latest speech on the subject and compare it with what can be seen in the HIFI alpha, you’ll see it is pretty much the identical.

  • Walter Balazic

    Since you focused Littlefield on the thread without actually explaining why we don’t allow Kitely market delivery, I just wanted to remark that the reason Littlefield doesn’t allow Kitely Marketplace is that it utilizes an open port in the asset server in order to deliver items. Opening a hole directly into the asset server could potentially allow someone to utilize it to attack the asset server directly which in our opinion is hazardous. Until another method other than “direct injection” into the asset server is available for distribution of products by an outside entity which we have no direct control over, for the safety of our infrastructure and community, that’s how we choose to proceed.

    • Geir Nøklebye

      Honestly I am not sure how this is any different from the injection that happens in your asset server every time a hypergrid visitor arrives at your doorstep. For every visiting avatar you will see a significant number of assets, including scripts being placed in the asset table of your database permanently.

      • It is the exact same mechanism as the one used by the Hypergrid protocol.

        • Geir Nøklebye

          Yes, so I don’t see the issue unless you have a general issue with Hypergrid.

      • Walter Balazic

        If that’s the case, why do I have to open a port just for Kitely? It’s not the same mechanism as HG.

        • You don’t have to open a port just for Kitely Market, it uses the same one as the Hypergrid protocol does. You do, however, have to not block the insertion of items from our marketplace to your grid’s asset server which your grid does and other Hypergrid-enabled grids don’t do. In other words, your system actively blocked our deliveries. Had you not done so Kitely Market would have worked with your grid without any special configuration on your part (just like it does with other Hypergrid enabled grids).

          • Walter Balazic

            We blocked any ports “not” required by HG. Your port is not a standard HG port. We have HG visitors everyday, and none of them have any issues, and that port is blocked. Is there an explanation for the fact that blocking “that” port stops Kitely, but no other HG assets?

          • Our system accesses the ports your grids reports. Closed grids can be configured to use special ports for Kitely Market but you don’t have to make such special arrangements if your grid is open to the Hypergrid and doesn’t intentionally block our system from accessing the grid services listed here: https://kitely.atlassian.net/wiki/display/doc/How+To+Enable+Kitely+Market+in+Non-Hypergrid+Grids

            As you know, firewalls can be configured to block certain third parties while enabling others. They can also do that automatically if you set them to block activities that they consider to be suspicious. The fact that people were accessing your grid via HG doesn’t mean that your firewall wasn’t blocking Kitely Market at the same time.

          • Walter Balazic

            But you just said it uses the same protocol and port as HG users. Either it’s using the same ports and protocol, or it isn’t… I have Kitely users on the grid via HG all the time with no issue, and HG users from other grids here all the time as well, also with no issues. We didn’t “intentionally” block your system when it initially failed delivery, our firewall blocked it because it’s not a standard HG port. You require a particular “non-standard” HG port to be open in order for marketplace to function. We setup our firewalls as per Opensim specs for what ports need to be open for the HG protocol to operate properly, and Kitely Market failed delivery because it’s not part of the standard HG protocol / port set of parameters. I never said that it doesn’t use a similar technology, I said that it requires a port that is not part of the HG standard port set in order to function.

          • Kitely Market uses the ports that grids report that they are using as there is no point in trying to access anything else – there is no relevant service listening on other ports.

            I didn’t say our marketplace uses the HG protocol, I said it uses “the exact same mechanism as the one used by the Hypergrid protocol” (calling the same service endpoints but not necessarily in the same order, under the same conditions, and/or at the same rate). We’re potentially transferring many bought items to one of your grid’s avatars, which may not be currently logged in, and must ensure that all those items will be accessible when the user is informed that they have been delivered – the HG protocol doesn’t ensure that (at least not at this time).

            You’ve set your Firewall to block that “suspicious” activity, which is your prerogative, but that was a choice that hasn’t been made in any other grid we’ve encountered thus far. It is also something you can easily change back to the default setting (for everyone or as a special exception for Kitely Market). It’s your grid, it’s up to you to decide whether or not you wish your users to be able to get items delivered from Kitely Market.

          • Walter Balazic

            Well unfortunately, our grid’s security is the priority, and any activity that our firewall system sees as “suspicious” we block. When you have another methodology of pushing content or providing content to the HG community, let me know and we’ll be glad to allow Kitely Marketplace at that time.

          • Geir Nøklebye

            You have to make your own considerations for your grid, but to base your decisions on what your firewall reports alone seems a bit odd. A person always has to evaluate and make risk assessments on what the firewall “says”. It usually will give a lot of false positives.

            I sincerely hope you will re-evaluate export from your grid, as there are many excellent creators there who have their creations confined on LittleField.

          • Walter Balazic

            This has very little to do with our “export” policy. Our content creators items are restricted to our grid at their request. This was the policy we adopted when the content creators their made the request that the content stays ON Littlefield Grid only. They have communicated to us that they create the content for the Littlefield community, and they want it to remain there because the community there all work together on projects, and they are assisting each other on these items as a group. They have indicated that they don’t want Littlefield to be HG Mall. Simply put, they don’t feel that a HG user coming in to get content and leave contributes anything at all to the community and since the content is free, they see no value in opening it up to the HG at large.

            As for basing our decisions on what the firewall reports, we don’t. But we do use the software to determine if something is suspicious network activity in order to protect the servers and the community. Rather than us making a correction in how our firewall system determines something is a potential attack or suspicious maybe Kitely could use a method that wouldn’t trigger a firewall system to show it as an attack or suspicious activity. The software sees it as suspicious for a reason, and rather than bypass that, if we have to forgo having content come in from Kitely for the safety of the grid and the servers, that’s what we’ll do.

          • Kitely Market isn’t attacking your grid or any other grid. The only time it delivers content to a grid is when someone buys items for delivery to an avatar belonging to that grid (there are no freebies in our marketplace).

            You stated you have no problem with Kitely users teleporting into your grid via the HG so you obviously have no issues with content arriving over the HG from our grid to your asset server (or from any HG-enabled grid or standalone for that matter). Why would someone pay us (to buy items for delivery) when they can insert an unlimited number of assets into your asset server via the regular HG route for free from so many other sources? You are not gaining any security by blocking our marketplace delivery system from delivering items to the same asset server, using the same service endpoints, from the same source, in a slightly different manner.

            As long as your grid is HG-enabled, blocking our marketplace delivery system is little more than security theater. You’re paying in reduced utility for your users while not closing any actual attack vector against your grid.

          • Walter Balazic

            When Kitely Marketplace is part of CORE Opensim/HG code, I’ll be sure and open that port. And you can’t guarantee the open port caused by your market won’t garner an attack, so before you make claims like that make sure you can guarantee it.

          • Kitely Market is not a core OpenSim service and we have no intention of contributing its OpenSim-related code to core. But, as stated previously, its HG-delivery system uses the same ports that the HG protocol uses and it uses the same grid services that the HG protocol uses. See the aforementioned link for the exact services it accesses and note that all of them may be accessed by HG visitors to your grid.

            You don’t need to open any port that you don’t keep open for avatars visiting your grid from other grids. You just need to ensure your Firewall doesn’t block those same ports when Kitely Market tries to use them.

          • In my experience with firewalls, they often throw up false positives as Geir mentioned. In this case, it is picking up the attempt at accessing the port as potentially suspicious.

            If I connect to my Dads PC (he often needs help with stuff 🙂 ) from my PC, both our firewalls will throw up a warning. But we are both aware who is on the other end trying to connect, so we add the action to the whitelist. Now, if I have a virus or my dad does, we run the *very remote* risk of cross-contamination. But so long as you trust Kitelys system is clean, thats not an issue here.

            Otherwise though, this is a similar situation. Your firewall is basically saying “Hey, this MIGHT POSSIBLY be dodgy if you dont know who/what it is!”, but you are aware that the 3rd party trying to connect in this case is Kitely, so you can add the actions to the firewalls “recognized action” or “whitelist”. There is no risk of something else getting through, as your firewall will recognize the signal as coming from a different place and throw up a new warning.

            Firewalls can protect you from potential threats, but they are not all-knowing and make decisions based on probability. If you know the action coming from a safe source, the probability of attack falls drastically, but your firewall cant know or understand this factor.

            It doesnt know that you want things delivered from some external source somewhere, you have to explicitly tell it. Only you know exactly the connections that should be functional.

          • Walter Balazic

            “Now, if I have a virus or my dad does, we run the *very remote* risk of cross-contamination. But so long as you trust Kitelys system is clean, thats not an issue here.”. And that is our point. We simply don’t trust Kitely with our grid’s security (or any grid for that matter that would use this type of method to communicate with our asset server). We don’t know what failsafes they have in place, or what their security is like (obviously they use a known security vulnerability as a delivery method to Opensim grids for example). The security of our grid is our responsibility, and to be blunt, Kitely’s prime focus is money, not our or any other grid’s community, server security, user base or content. If they have an issue that causes their server to be compromised we don’t need that comprise on our grid. HG itself has security in place which protects the ports due to work that Diva has done in securing vulnerabilities in the HG protocol. As stated by Ilan himself, this isn’t a core Opensimulator protocol so it doesn’t get the attention from the development team for security that HG itself does.

          • There are two STANDARD built-in ways to get data into an asset server, using pull and using push. The HG protocol uses one method and Kitely Market uses the other. We aren’t using any security vaularability as a delivery method. We’re using a sanctioned method that is part of the standard Hypergrid API that Diva developed.

            Again, you’re not gaining any security by allowing one standard method to be used while blocking the other. Especially when you allow anyone whatsoever to access the first method and are blocking the second method from being called by a company that is part of the core OpenSim developers group. A company that has intimate knowledge of OpenSim’s internals and has contributed code that you’re running on your servers. There is NOTHING that can be done using the method you’re blocking that you don’t already allow ANYONE (including Kitely) to do using the other method. As I stated earlier, you’re practicing security theater without gaining any actual security by blocking one sanctioned method while allowing the other.

          • Walter Balazic

            If you were using the standard method Diva developed, it would work just like HG users accessing our grid work with their inventory. HG users don’t trip our security when they enter and their inventory loads, Kitely Marketplace delivery does.

          • Walter, I assume you’re a person with some technical competence so just browse OpenSim’s source code and see for yourself who added the capability that enables the caller to push assets to the asset server via the Hypergrid. If the method wasn’t part of standard OpenSim we wouldn’t be able to use it to deliver to grids that are using standard OpenSim. We wouldn’t build our marketplace delivery system on a method that we couldn’t rely on existing. If it were a hack we wouldn’t have been able to rely on it not being closed down by other core developers..

          • Well, naturally nothing is ever 100% risk free or foolproof, and everyone is entitled to their opinion, but I think your massively over-reacting.

            Of course, you are correct that Kitely Markets main focus is to make money. But I contend your point that Kitely are not interested in other grids security. That is (respectfully) utter nonsense. If the Kitely delivery method posed a security threat, nobody would use it and Kitely would make no money. So security is an intrinsic means to an end in this case.

            As Ilan has expounded in great detail, its not a “hack”, its not a security risk (see Ilans comments below). The example I gave with my dads PC via remote connection; exposure to a virus is more likely because we share the entire desktop. The chances of someone writing a virus or malicious code specifically to infect Kitely packages sent from the MP, defeat Kitelys security and somehow get it operational is so infinitesimal it boarders on totally irrelevant. But as I said before, your firewall does not know this. It treats all things equally.

            So far I have sold products to dozens of people on dozens of grids for nearly 2 years now and to the best of my knowledge, nobody has had any security issues. I am sure many other sellers can say the same. If this was actually an issue, dont you think of all the other grids Kitely delivers to would also have had issues?

  • Walter Balazic

    And before anyone goes on a tangent. Yes you can firewall just that port to allow just Kitely to access it. Of course then you are relying on Kitely to keep “their” system clean and virus and attack free, and not push things to your asset server via that port directly into your asset server.

    See excerpt from Kitely’s instructions on allowing access to market below:
    (taken from: https://kitely.atlassian.net/wiki/display/doc/How+To+Enable+Kitely+Market+in+Non-Hypergrid+Grids)

    “In order to enable delivery from Kitely Market, you will need to make some Hypergrid services available. But you only want to allow Kitely to access these services. This can be accomplished by running the services on a special port, and using the firewall to allow access to this port only from *.kitely.com. We suggest using the following port:

    Port 8102 – open only to Kitely (using the firewall). The number “8102” is meant as a reminder that the services that use this port usually use port 8002.”

  • Of the open virtual world platforms you listed only OpenSim has a big enough customer base to justify the effort of supporting it to
    date. realXtend, Aurora Sim, and White Core have nice technologies but hardly any users. High Fidelity just started their public alpha so there was nothing
    to support until very recently (and avatars are sill lacking a viable
    inventory system in that platform).

    Kitely Market began with delivering to OpenSim but we’ve already
    announced we’ll support delivery to High Fidelity and additional open
    virtual world platforms in the future. For details, see:
    http://www.kitely.com/virtual-world-news/2014/10/24/kitely-market-to-support-high-fidelity

    The list of closed-source virtual worlds is quite long but almost all of those platforms are no more part of the metaverse than Minecraft is (which has a much larger user base than all the VWs you listed). The VW you listed may all include an element of user generated content but they are closed gardens that are controlled by a single company and can be shut down with little to no prior notice. They are not the virtual world equivalents of the internet, they are more akin to virtual world equivalents of bulletin board services prior to the first web browser becoming available. Some of them are great but I doubt they can evolve into becoming an integrated part of the Metaverse.

    Our goal isn’t to delvier to any game/platform that has avatars. it is to deliver to VR/AR platforms that aim to become the VR/AR equivalents of the internet (i.e. the Metaverse).