Slashdot Mirror
Ask Slashdot: How To Get Paid For Open-Sourcing Your Work?
kc600 writes "Say you're a freelancer, using mainly open source solutions. You notice that customers, although they don't object to the whole open source idea, don't see the point in paying you for the time it costs you to properly open source your code. As a result, code is not released, because it would take too much time to factor out the customer-specific stuff, to debate architecture with the other developers, look at bug reports, et cetera. You feel there's something to contribute that many might benefit from. The code would also be better maintained if more people would use it, so the customer's project would also benefit. But you're not going to do it in your free time; you have enough on your mind and the bill is paid, right? What useful tricks can you think of to encourage yourself — and your customers — to properly share code, to the benefit of all, and get paid for it?"
The hard question really is "how do I convince people to give me money for writing software?". Open or closed are just details if it's being sold as part of a provided service.
Get Paid! Big business strategies for the small business person.
Don't open source it.
DO: The old MySQL way of selling FLOSS seems fine to me. See also: MySQL.
DON'T ask for subscription money to open source your work, this is called "pulling a lunduke". See also: lunduke.
In general, read up on the works of Bruce Perens. See also: Bruce Perens.
If you want to get paid to write software then you're writing it for a company. If you want to write software to give away then stop expecting people to pay you for it. They want something for them. Not something for the world to use. By expecting to just give away their code you're telling them you're not focused on their product for their company. And why would they pay you to write software that a competitor can just use for free? If no competitor would use it, then why are you making it open source?
If you want to contribute to open source then do it on your own time with your own money.
It seems to me the bigger problem is that you're not a programmer, you simply find existing things that kind of do what the customer wants and piece them together.
If you can't write custom code for a client without using GPL code then you're not very good at your job.
And if you can't see the stupidity of giving something away that a client paid you thousands for then there's no help for you.
Work Safe Porn
advocate told me; YOU should not make money from open source but from other work. (support and crap like that)
I asked him why he (and Stallman) was getting paid but I shouldnt be? The reply? We are not, our companies/institutions are.
So there you have it: Wanna live of making opensource? Start working for a mega corp or a university.
http://en.wikipedia.org/wiki/Johnny_Appleseed
When I open sourced the programs that had made me some money, but I had no time nor the stamina to keep working on them, I didn't expect to get paid for that.
Instead, I thought of Johnny Appleseed.
The programs that I open sourced, to me, are old stuffs. I could have kept them under closed source, store them in CD-Rs or external hd or old computers, or ....
I could have done that, but if I did that, it wouldn't benefit me, nor anybody else.
When I open sourced those programs, I didn't even know if anybody else wanted them in the first place. I just placed them online, did some advertisement on related sites, and then, let go.
If the "appleseed" blooms, good.
If they don't, well, it'd be the same as I locked them up in CD-Rs.
The most important thing is that I've set them free. Their "lives" after being set free depends on their "fates", or in spiritual kinda speak, "karma".
Once they are open-sourced, they do not belong to me anymore. Now, they belonged to the world.
Muchas Gracias, Señor Edward Snowden !
When someone is paying you, it's "their" work. They are paying you to build something they own.
You no longer own it as soon as you cash the check for the work you did.
Work Safe Porn
Why should your customer pay you for something you want to do?
You simply deliver them a solution and make sure the code is GPLed. Release engineering you can do in your own time, which when done right is an investment in future business because you can re-use the code for another client, deliver better solutions because you got some (free) help improving the code from random strangers, that sort of thing.
As a foss freelancer, you're much more a consultant than a software manufacturer. Amend your mindset as appropriate.
Why are you delivering code to your clients in a state that you're unwilling to publish?
If you are serious about this, then make it an integral part of your "business plan" and put in your contract that open-sourcing the project non-negotiable.
REALLY you should SELL your customer on the idea that the software THEY ARE PAYING FOR will be BETTER.
If you have to factor out custromer-specific stuff it means that your code is not well refactored and does not have clean interfaces. While you are writing code for a customer, you should take care that at the end you can release your open source parts immediately. The extra time this might cost is quickly returned, because your code will be cleaner and easier to develop. It will also result in component that are beter to use by others, because they do have a clean interface. One reason why open source components are often not reused because they have a bad interface. Refactoring is a great technique to develop clean interfaces. You will benefit it from yourself if you learn to create clean interfaces. It is an art not easily managed, I have come to realize.
Put in the contract for development that either they will have to pay you a maintenance fee, or pay for maintenance on an hourly rate when required. The third option we that If they choose to open source the code you write for them and it gets accepted in the project you wrote the extension for, they will have the option to use that maintained code. Let them make the choice, at least this will give you an option to work on it as an addition to an existing FOSS project, or some custom thing from the very beginning. By starting out already knowing which direction you're going, the difference in development time will be less than if you have to re-write everything to get it merged with the FOSS project.
I was promised a flying car. Where is my flying car?
Use linux as an example; it's open and because of that it has spread to every bit of hardware in existence and has become the most robust OS.
That's because of all the eyes on it. You can't have that without opening.
Tell your client to open their eyes and they'll profit from all the eyes when you can't meet the demand.
They'll see results with their own eyes.
I work for a 5-person tech cooperative. We were writing code, documentation, etc. that we wanted to contribute back to the community. So out of our "profit", we made sure that we set aside some funds for our members to spend some of their time abstracting code, packaging it up for release, etc.
The basic principle is the same for a freelancer - you have to raise your rates. Are you charging $100/hr? Charge $110/hr. Use the extra money to pay yourself to package up the code.
In terms of "useful tricks" - well, as a freelancer, you don't have the privilege of someone keeping you honest to your goals. You can change your personal rules whenever you want. But frankly, I would say my co-op has made a net PROFIT on open sourcing our material. When we open source it, we post about it on our blog, Twitter, etc. This increases our referrals from other developers, it means more folks are finding us on the search engines, we gain credibility with other developers when we need them to fix a bug in their module. Maybe the "trick" is to remind yourself of those advantages.
I have been paid for writing open source software but only in the following context:
Open source project X almost meets our needs, however it is missing the following 3 features. I could spend two weeks implementing those features (but we will need to contribute it back to the project) or two months implementing the library from scratch, which do you prefer?
Basically, I would say that you need to present a very concrete value proposition in front of the customer and let them pick... starting an open source project as a contractor and on the customers dime is pretty much always going to be a non-starter.
open source initial release, and if its good, hold of improvements/updates/bug fixes until a donation meter reaches a certain amount
dunno if you would get a lot of money that way, but you might get a bit
This is a non-issue, and the only reason such a question can be asked is being a part in a propaganda campaign against open source software.
Contrary to the popular belief, there indeed is no God.
If you were meant to be a success at writing open-sores software, you would be able to subsist on toe cheese while crashing in the random living room.
Develop the code, then create a not-for-profit organization and donate the code to it and write yourself a tax receipt.
Why did you think Mozilla, Apache etc are all not-for-profits?
Mod this up to the skies, please! In my opinion this applies to -everything- forgotten books [I've been thinking about trying to find the rights owners for some of them], forgotten music [same problem, I'm from the 60s there's some wonderful stuff buried] etc. Unhappily, for me, this non-publishing is collateral damage that [in the spirit of Bentham: http://en.wikipedia.org/wiki/Jeremy_Bentham%5D should be increasing the sum total of human happiness and instead lies locked or buried.
The second point, for software etc., is the 'standing on the shoulders of giants' idea. That is, something fairly simple or a few bits can be used to build something spectacular or inspire it. Same point of inspiration idea for music too.
Great post with a great many 'extra' implications, thank you.
On y va, qui mal y pense!
I recently successfully persuaded the company that I freelance for to open source a core part of their product line. The part we open sourced was essentially the engine that powers several other products. I had a whole page of benefits prepared, but the main one was this:
"Your developers don't seem to realise that the core engine is supposed to be a general purpose platform, almost like an operating system - it needs to be very well documented, and it absolutely can't have any code in it that is specific to one of the applications that runs on it. If you open source it and give it its own website and code repo, your developers will finally understand what it is, and stop dumping application specific code into it when then need to implement a new application-level feature. This will save you time because you won't have to be constantly refactoring application code out of the platform."
Also, "open source is cool, and having an open source product will make it easier hiring new developers" seemed to go down well.
foo mane padme hum
I worked on a closed-source product once where one of the customers wanted to pay for a new feature to be developed, but under the condition that it would be included in the main product and not developed as a customer-specific extension. The reason was that they wanted to make sure the feature would be maintained and that the maintenance would be included in the base license costs.
Opening the source could be part of an effort to reduce future maintenance costs, so that would be a way you could sell the idea to your customers. That would obligate you to actually use the same code for multiple customers as much as possible, of course.
In terms of who pays for the hours spent generalizing the code, I don't think it's fair to charge the first customer for this. Either increase your hourly rate and do it in your own time, as one of the other posters suggested, or charge the subsequent customers for it, since they will be the ones benefiting from the fact that the first allowed the source to be opened. Besides, generalizing code while you only have a single customer often leads to bad design decisions since you'll have to make assumptions about the requirements of other customers without having talked to those customers yet.
This is a core problem with open source.
- Customers see no value in your work, so you either force a revenue stream with subscription or ads
or
- You make your customers see value in your work by placing a budget. eg "next feature update at 500$" and keep
raising the bar until you're in a comfortable position. I've seen this work for games and some useful apps, but probably only works for established content.
or
- You make no commitment or support except to paying customers (a la mysql, redhat, etc)
To take a page from the art/comics community (which has the same problem)
- Put your content online for free at legible resolution/ad-supported
AND
- Put your content into print if there is enough demand
AND
- Sell Merchandise (tshirts and hats) for those who want to support your artwork.
A lot of the time, the reason people aren't making money off of their open-source content is because they're too ingrained in the GPL mindset as opposed to the BSD minset.
GPL = more or less source code communism, by which anyone can fork your project and make a better one, and then turn around and demand your improvements be shared. Nobody gets a chance to monopolize it (see Oracle buying MySQL or OpenOffice)
BSD = more closer to public domain with some copyright attached, by which anyone can fork the project and make a better one without sharing improvements. So this is more "Captialism" in nature of taking a public resource and commercializing it.
From a political standpoint, if you want to be open source, and never charge for source code or binaries, that's great, because it drives adoption of your software. But the pitfalls (especially for games) is that something better always comes along.
Like what I want to see is someone do an open-source MMORPG. It has all the right opportunities to monetize and get improvements made by the community who plays it, and I'm not talking about Second Life or Minecraft. I'm talking about a game that the actual game mechanics, storyline and assets can be created by the users.
Open Sourcing & getting paid are not incompatible. In general developers are very bad at marketing their open source software - poor website design, very technical explanations (if any) .. remember people who are NOT going to pay for your software are people who are probably as skilled as the developer .. they won't spend any penny and can quickly figure out how to use your software. The people who might pay for your software are people who are not very tech savvy, need to solve a problem for 1/4 of the price than if they were to go with commercial software.. usually they won't mind paying for the software to be installed by expert hands and might as well buy extras from you .. just be creative as how you can make money : ongoing support, user manual, extra features (just like TV packages), value added (private) forum, and so on .. so YES it's possible to make money out of open source software, if right from the beginning you think Service, Service, Service
Negotiate Before You Buy
Charge them for access to the software. Open Source doesn't mean free as in beer. I can't believe that no one has mentioned this yet. Open source only means that you also give them the source if they use the software. And if you aren't charging for the application you have no responsibility to maintaining it. You can't complain about not getting your money's worth for free software without coming off with entitlement issues.
I am an open source BI consultant, we use loads of different open source software when developing solutions for clients. Sadly clients don't always pay for the open source software, they believe open source is free.
That being said we also offer a piece of open source BI software, until yesterday (this is true) we were GPL based, and to be honest dealing with requests regadding embedding, in a SAAS solution, not in a SAAS solution, was a pain in the ass. So we changed it to Apache 2 now to make our lives easier. All that aside, we have found that our clients really pay for open source software when they feel they will need support, people don't like to support other peoples software, so sell support packages.
On top of support we find that people are happy to pay for extra functionality, we offer cheaper development rates for people happy to include the new feature back into the open source version, if not we charge standard consulting rates. And last but not least, clients then find we offer a wider range of Bi consulting and we gain more work from that.
So we find that offering extra services on top of the software is what makes us our money, the software itself, whilst people pay for, isn't what keeps us afloat.
The first time you implement something, you don't know there's a market for it. You write something that is very specific to your customer's needs.
The second time you are asked to implement it, you have a known demand, and you have a chance to resurrect the old code and make it better suited to a wider variety of uses. You can charge the second customer the amount it would take to implement from scratch, and use that time to clean up and prepare your previous work for their purpose and for general audiences.
I'm astonished about this question.
Any freelancer has a per-hour price that also covers other not directly billable work, including customer acquisition, tax reports etc.
If it wouldn't be so, the freelancer work would be at loss.
Now, please explain why you can't charge a price that is sufficient to cover all your extra duties, including open-source work.
Don't open source it. All the contracts I've had specifically state the IP is owned by the company I contract to, not me. I wouldn't have the right to open source it.
As other posts tell, if you want X to pay you for a work, you need to convince X that such work is interesting to him. Just saying "I want to open source it" is not going to impress anybody
An option, if the product has a functionality common enough, would be the possibility of creating a base of developers (that may add some useful functionality) and users (aka as "testers").
This can be combined with a marketing or "coolness" approach so that such company can be seen as providing something for free (don't they give free pencils?).
Why can't
We've all had this problem. Recently, I started working for a company where, rather than using the upstream as the git base, a deployment profile was based on a make file (drupal, using drush make), which pulled in the base software, and applied various patches as required, and create the install profile from that.
As a result, the standard operating procedure when hitting a bug, or creating a feature in an upstream contrib module was to create an issue on drupal.org (if one didn't already exist) and then submit a patch for said issue, which we'd then reference in our make file until it got pulled into upstream.
The result was that because this was common activity, rather than a big single event, we did it all the time. The norm was two or three line patches that fixed an annoying bug, or added a useful feature, and it helped us with keeping our installs up to date, because our modifications on top of upstream modules were cleanly seperated out.
It also helped that drupal.org had a easy common way to create issues, and attach patches to them.
I work for a company that does a lot of Open Source stuff. Here is how we manage it: We have core toolkits that are open source, and custom applications that are closed source, made for specific customers. When ever a customer needs new functionality, we try to generalize it and put it into the toolkits, which we then release. We tell the customer that we have this open source toolkit which we use for the project, and which we keep improving. But we don't specify how much of the work goes into the toolkit, and how much on the custom side.
Those toolkits have been our main marketing effort, and have certainly paid off. Within our very narrow field we are world famous, and our toolkits almost dominate the market. Nobody can afford to build a competing one, when ours is free. Although anyone may use our tools, we happen to know them best and have most experience with them, so we can often do any given job faster than others. The company has survived over a decade, and has expanded internationally, and is now all of 15 people.
In Murphy We Turst
Just share it, and remove the very minimal (i.e. any hardcoded passwords/api keys you might have).
If anyone is interested on it, *they* will take the time to factor out whatever doesn't fit them. Or at least they will nag you about it, so you know which parts are more prioritary. If no one is interested on it anyway, then the project is not worth opensourcing, and you should not invest more time on it anyway.
If you think they might listen, you may try to convince them by pointing out that making parts of the system open source has a number of advantages such as free code reviewing and bug fixes by the community. Basically, you need to show them that they get a good return for their investment.
Share code, get paid.
Sharing implies giving.
I have been in the Open Source business for almost 10 years now and I am leading a big open source software project which is completely self-sufficient.
From my experience what you need to sell is not a 'Please open source this software because other will benefit from it' but a 'Please open source this software because YOU will profit from it - in the future'. Open sourcing a software is usually a bet on future option, like a stock option you are creating which needs constant nurturing.
Tell the customer that with a regular maintenance fee he might be able not only to help you support him (in case of problems/bugs/general support), but also will be able to extend it with possible new features with no additional costs (beyond that maintenance fee).
The 'do it for the public common good' is certainly weighing in on your suggestion but certainly a future investment and return is the key point. At least this worked for me/us. Usually if additional features happen they will be so happy and donate on top, too.
Spelling errors were made for your amusement only...
The core idea is that costs are shared by co-operation between parties who have a similar need. This is not a new concept, and has appeared and suceeded in many different forms in business. Like a 'franchise' which shares branding costs because it would be impossible to get the same level of branding on their own individual budgets. There are other reasons to opensource your code (fame, altruism, etc) but these are not very appropriate in your context.
And if you can't see the stupidity of giving something away that a client paid you thousands for then there's no help for you.
You could offer a discount to your customers if they allow you to open source the code. This benefits everyone. Your customers get a nice discount, and you get to open source your code and potentially help speed up your development time on subsequent projects. To get around the drop in income, you could raise your baseline rate and encourage your customers to take the discount.
Alternatively, you could just focus on refactoring and open sourcing the code in your own free time.
(background: I've been freelancing for about twelve years, with several engagements that have resulted in open source contributions)
If you're freelancing, the general rule is that the customer owns everything you produce within the scope of the contract. This means you do not own the copyright, and therefore you can't open source the code. The specific phrase you look for in your contracts is "work for hire" ... and although IANAL, I believe this is the implicit legal relationship when someone pays you to produce something.
It's very difficult to get around that rule, or to outline specific exceptions ahead of time -- but you can change the incentives to encourage your client to contribute code to the open source community.
I offer to reduce my rates for any work we mutually agree to release as open source. I benefit by getting my name and work in broader distribution, my clients benefit by paying less for the work, and the open source world grows a little bit. It's a reasonable trade off for all parties, and even if most clients don't exercise that option, they appreciate the spirit of such an offer.
Where it gets hairy is when you're making changes to code that has been open sourced under a "viral" license, like the GPL. If that is the case, then you should inform your client that they are bound by the terms of that license -- that those changes *necessarily* become open source. Keep a copy of those emails. If your client decides that they're going to skip out on that obligation, you'll want to make sure your ass is covered if/when your client gets in trouble ...
Closed source: they have to buy in someone to fix it or improve it. They make no money from it being closed.
Open source: they potentially get free fixes. They make no money from it being opened.
Additionally, since it is opened source by an independent contractor, there is no reasonable trait of ownership of the code by the company. If there is any complaing about patent or copyright infringement, they are not the owner of the code and are not responsible for the complaints redress.
There's no need for it to be closed source.
Get your Boss's permission and Open Source it in your spare time. Jesus, it works like this in the Open Source world.
CLI paste? paste.pr0.tips!
To refuse would be cutting your nose off to spite your face.
If your competitor gets someone to write an improvement for them, they have had to pay full wages for it. This company could do the same. If it was closed source, then they would HAVE to get someone in and pay full wages for an improvement. But open sourced, they may get improvements for free. So just to spite the competition in the remote possibility they would bother to leech off the GPL release, you would refuse to get free improvements?
Penny foolish AND pound foolish.
so they can do anything with my code they want; I don't want that code anymore, let them have it. Most of the time it goes to the trashbin anyway (nowdays agile means reiterate forever).
Roll the cost into the project. If I need a new Hot Air Rework station I add the cost of that to the next project that needs one. So that $22,500.00 job becomes $25,500.00 The customer still buys it and I get a nice shiny new Tool.
All businesses do this, Why is this not understood by freelance programmers?
Do not look at laser with remaining good eye.
Charge a little less when they allow you to open source it compared to when they don't (put it in the contract up front).
Money talks.
I started coding for hire when I was 15. The way I approached it was, $30/hr for normal work, $25/hr for OSS development, and it had to be decided at the start of the project. Developing OSS usually required a bit more time because more work had to go into writing unspecialized, portable code in contrast to a project that stuck to a strict spec. In return you got more frequent updates/new features and a "sponsored by" pat on the back on the website and within code comments.
Current IP law surrounding patent and copyright protections are absurd. But the intent of those laws is not - to provide limited protection to encourage innovation and progress. So do what patent and copyright law should be doing - provide *limited* protection. License your code under restrictive terms - but only for a limited time. Then release the code. Just because you *can* retain indefinite control over your creations doesn't mean you should.
The fundamental problem is that typically you write software for the customer and then it belongs to your customer and not to you - so one way or another you have to involve your customer in this decision.
"Only one thing is impossible for God: To find any sense in any copyright law on the planet." - Mark Twain
The fundamental problem is that typically you write software for the customer and then it belongs to your customer and not to you - so one way or another you have to involve your customer in this decision.
It all depends on how the contract is worded and the agreed upon license. It's also a lot easier to ensure open sourced code by building upon GPL'd frameworks, which in most instances is required to be GPL'd as well.
Sure. And some people complain about people complaining about Ubuntu not contributing enough.
In both cases, no one really cares about their complaints.
To you I say: if you don't want to be painted as a linux advocate by virtue of posting on slashdot, then don't try to paint the linux community with that sort of broad brush.
There's a shop I used to work at in the past that did kernel ports to custom architectures, custom drivers, etc.
Now, you could pay us to do the work and keep it in-house... and when a new upstream kernel version came out, you could pay us to do it again.
Or, you could pay us to do the work, and pay us to do the extra work of getting it upstream once... and not have to pay for ports to every new upstream release.
We didn't have to try very hard to sell the second option.
He's not writing operating systems.
Work Safe Porn
Basically whether you're doing "work for hire" or working independently. If independently, you could have a clause saying that anything you write independently is licensed by default under the GPL, with a dual license giving the company non-exclusive rights to use/modify/distribute.
If they want exclusive rights, they get charged more because it means you can't reuse that stuff later (and you can't reuse stuff from previous jobs).
My standard contract has a brief paragraph explaining the open source ecosystem, how we could start each code block from scratch instead at much greater cost but we'll use open source whenever possible to improve cost, time, and quality, and stating that software modifications tangential to the core business of the client will be fed back upstream, unless the client requests otherwise.
Deal with the issue once.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Charge more if the code is not open sourced.
$150/hr for non-F/LOSS coding.
$120/hr for F/LOSS coding.
Money will often make them change their minds.
Open-Source start-up business in every big city shouldn't be to hard. IF THE GOVERNMENTS AT ALL LEVELS DECIDED TO MIGRATE TO LINUX (Servers, Workstations, Desktops, Laptops). Get a contract to audit the source code, add features to applications, remove features from applications, etc. EVERY GOVERNMENT DEPARTMENTS AND COMPANIES IS UNIQUE AND WANT DIFFERENT FEATURES WITH THEIR APPLICATIONS. It's like having a suit created to fit your body. Open-Source should be able to create a lot of computer careers in Open-Source Start-Up Business. I'm just hoping that the government(s) wake up and create laws to migrate to Linux ASAP.
Why bother getting paid? Why would you want to reap the benefits of your own work? And donate your time and efforts to maintain something?
Oh yeah, that's right. All these little whiny hacker wannabe's stealing software and music because they don't want to pay for it! They all make the argument you should not be compensated for your work, you greedy bastard.
Do as I say, not as I do, right?
1. Get U.S. Passport at any Post Office
2. Book flight online to Moscow
3. Fly to Moscow
4. Walk to different buildings of Tech Companies in Moscow and ask for a Job
5. Get paid top dollar for your hard work and live in luxury!!!
6. Profit !!!
you can write whatever you want into the contract. Microsoft did it, so why not you? Just write that it doesn't belong to him, they do, too.
EOM.
Set up an account, kickstarter, whatever. You get $1000, the code goes free. The donators pay if they all together hit 1000.
Increase your rates by 25%, and then offer to take 20% off your rate if they allow you to open-source the solution. Existing customers may complain a bit, but new customers who didn't know what your rate was anyway, will think you are offering them a deal.
Mostly people want a problem solved, are paying you for that, and don't paticularly care about what happens with the software you use to solve it.
People don't care if the details of for instance a database backend or something to deal with forms or whatever stay secret or not, they only care that the data in their database or their custom forms (or whatever) stay secret.
Very few places are in the business of selling software so most places really get no direct value out of stopping you from reusing what you've written to solve their problems.
You make a library of funcitons on your own responsibility, which itselfs forms not a complete product, open source it,get more efficient in composing your products. Your customers will not care very much about it (they want that you do the job, fast) and you can complete more projects by using the shared code. With a little luck, people will start to contribute to the library and there will be a synergy.
That is how i understand most open source projects works: provide the building block open/free (on your responsibility) and build the final product (closed) for the customer.
The myths about not being able integrate GPL components into a complete commercial product is just not true. Where i work there is a process for defining and managing obligations from the usage of open sourced code. Once this is standardized, its actually not complicated or difficult at all. If a customer doesnt understand it, explain it.
https://bountyoss.com/
is known as the recognized representative of the luxury, it not only has a distant dream of France, but also has expensive so the most difficult to accept price. Mulberry Bayswater Alexa Chung is good for you. In addition to pre-opening, dressed in black security people stop looking, the 16 level of luxury inside the house of Louis Vuitton is extremely magnificent. Domestic largest LV store opening