141–150 of 260 posts
If only this was voluntary and automated by an Open Source service provider, so that I only have to pay one monthly fee and all the FOSS that is detected to be in-use on my machine is funded.
It seems like it would be much less complicated to write this/enforce this if they just made you pay a subscription fee for access binaries and the issue tracker. Instead, they've generated an enforcement nightmare by solely relying on an EULA.
I love the innovation. The basic idea here appears to be: - Nobody wants this to be closed source. The code is freely available, and you may do with it as you want. The marginal cost to distribute the code is 0, after all. - The maintainers, as people, don't want to do charity work for companies. Their time is limited, and if they're going to support revenue-generating activities, they want a cut of the revenue. So e…
pull back the layers. This is the usual masking of the facts. A rose by any other name... is after money. FOSS is destroyed the moment that is introduced to the mix. Its like political sells - begin pushing a small degree, they wont notice the temperature as it rises over time until its closed source and corporate. This is how you kill off FOSS, or your project. "corporate creep" I call it.
Note: I'm not saying you're an entitled consumer, but I interviewed many maintainers of successful Open Source projects. The number one issue for all of them was entitled consumers.
Earlier quoted context omitted.
It's shocking to me that Microsoft aren't heavily involved with the project considering it's one of the fundamental frameworks for releasing software on Windows. I've had the displeasure of using Wix and it's an incredibly complicated and poorly documented platform that had us reaching for paid competitors in order to get our installer shipped. I realized shortly after that it's not really Wix's fault. Windows is squ…
> It's shocking to me that Microsoft aren't heavily involved with the project considering it's one of the fundamental frameworks for releasing software on Windows. The history of WiX is that it started internally at Microsoft. IIRC it was a project under the Office organization originally. It's generally considered the first big open source success of Microsoft in spinning a project out to open source community owner…
I worked in Office in 1999 when I created WiX but it definitely was not an "Office project". It wasn't until I left Office for project in Windows Server that Office adopted the WiX Toolset (to replace their custom system). The interaction with Office was always interesting.
> I've got a feeling Microsoft doesn't want to support it anymore because they see it as completely legacy today.
I think that's probably fair. The problem is that nobody has created an installation technology that is as fully featured as the Windows Installer. There are a lot of warts to the Windows Installer. It was designed to support floppy disks for goodness sake, but they were the last team IMHO that took the installation problem seriously. That's why MSI hasn't been replaced in 25 years.
> WiX toolkit is just a reflection of the complex legacy of the old terrible MSI output format.
Our primary goal with the WiX Toolset was to provide access to the full power of the Windows Installer. Given the adoption by extremely large software projects, I think we've done pretty well toward that goal. We're slowly turning our attention to simplifying the toolset to make it easier to use for simpler projects. But that's only been a focus for the last couple of years, so not a lot has come about, yet. But the Files element is a huge upgrade.
The WiX installer is a byzantine incomprehensible mess. Its only appeal was that it was free. If I have to pay, I'd rather have a commercial product that is supported and easier to use. Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services. I guess that's not enough.
WiX basically lets you directly write the internal data structures used by Windows Installer to run the MSIs. Just in XML instead of some ancient binary database that is used in the MSI files to store things. So the actual "byzantine incomprehensible mess" (which is indeed the correct description) is the MSI format and Windows Installer, not WiX.
> Our primary goal with the WiX Toolset was to provide access to the full power of the Windows Installer. Given the adoption by extremely large software projects, I think we've done pretty well toward that goal. We're slowly turning our attention to simplifying the toolset to make it easier to use for simpler projects. But that's only been a focus for the last couple of years, so not a lot has come about, yet. But the Files element is a huge upgrade.
There is definitely more we can do to make simpler things simpler. :)
The WiX installer is a byzantine incomprehensible mess. Its only appeal was that it was free. If I have to pay, I'd rather have a commercial product that is supported and easier to use. Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services. I guess that's not enough.
That was definitely its appeal to people who didn't want to pay anything for setup installation tools. But that definitely wasn't our only appeal or even our primary appeal. The WiX Toolset unlocked access to the Windows Installer in ways no other installation build tool does. If you didn't need that power then there were absolutely a lot of sharp edges and "missing features" to make your life easier. But if you had hard installation problems, those sharp edges were sometimes the weapons you needed to solve the problem.
> Rob Mensching was supposed to monetize WiX by offering $5,000/yr enterprise consulting & support services.
I don't monetize WiX for $5,000/yr. I monetize my team and my decades of experience building software installation packages of all shapes and sizes. With this "WiX Developer Direct" program from FireGiant (my company), you get monthly office hours directly with me to discuss whatever you want, you get SLAs for answers to tickets and guaranteed bug fixes so that your development team is never blocked. You also get an annual code review of your code by us and access to some high-end tools we develop. It is a high-touch offering and my customers dig it.
> I guess that's not enough.
That's not the case at all. The XZ Utils incident showed that Open Source sustainability is a huge problem and I was compelled to try to do something to address it. I don't think the Open Source Maintenance Fee is the only solution for sustainability, but I think it's a pretty good one for projects like mine. The WiX Toolset is the first project to adopt it because I need a real project to help work out all of kinks in the OSMF concept. Everything is working very, very well.
I came across this a few months ago when I was evaluating open source installer options for my own open source project. I have no issue with charging for binaries while the source is available under an OSI license, but this from the README rubbed me the wrong way: "To ensure the long-term sustainability of this project, use of the WiX Toolset requires an Open Source Maintenance Fee. While the source code is freely av…
It is challenging to describe the concept succinctly, especially as there are lots of varied expectations people have about how Open Source projects work. I'm definitely open to suggestions on how to improve the text.
Earlier quoted context omitted.
I agree with your point. In the name of promoting basic numeracy: """ Sign up for GitHub Sponsorship and create the tiers: Small organization ( 100 people): $60/mo """ You are beyond 'cash strapped' if $10/month for something as fundamental as this breaks the bank. The fully loaded cost of a single US software developer is already above $100/hour.
Sure, but that also doesn't scale reasonably and is entirely a facile argument. My original comment supports organization paying this price instead of dealing with internal compliance burdens. Looking at one of the package lock files for a previous company I still occasionally contract for, there are 9400 dependencies referenced. So in the name of promoting basic numeracy, and taking into account the realities of sca…
For example, IIRC, GitHub (all of GitHub) calculated they had 660 direct dependencies. That's still a lot but it's not 9400. :)
Not a lawyer so confused about how requiring a fee to get the binary is in practice compatible with open source licenses, which grant the right to redistribute said binary. I.e. even if the project itself does not want to give me a copy of the binary, anyone who has obtained that binary can lawfully gice it to me. Basically, my understanding is that as long as the software is released under an open source license it…
You're correct, but I guess they're banking on their users preferring to get the binaries straight from the source instead of through an unaffiliated third party. There are also other benefits to paying, such as being able to file issues against the official repository. Seems like a pretty reasonable compromise to me, to be honest. The license even says you may redistribute the binary you acquire from them: > User ma…
Yep. It turns out a lot of companies are willing to pay for maintenance but they aren't willing to pay for charity. The EULA is what activates the internal corporate mechanisms to make that happen.