This topic has been discussed at least twice before on this forum:
https://forum.xojo.com/t/thoughts-on-making-xojo-ide-open-source/12781
https://forum.xojo.com/t/is-it-time-to-open-source/15514
But as to your “Pros,” these are things that are good for you, not Xojo.
Xojo Inc. could devote less time to the framework and more time to the IDE.
What you’re describing is fine for a small project, but for a project the size of Xojo, we would need to have a team of people just to review and accept/reject changes. The people who would likely be most qualified to do that work would be the current engineers, since we’re the ones that are most familiar with the code. Ok, so instead of working on new features (or more likely in addition to), we’ll actually be reviewing the code of a bunch of people whose coding practices we have no control over and can’t do anything about, and then get ticked off when we reject the code it’s taken them a few hours to hack out. Wonderful.
Instead of suggesting that we open-source, I suggest you go through the forum and find the places where people have suggested an open-source community project to attempt to solve other missing Xojo features. Time and time again, there’s a flurry of enthusiasm at the beginning right up until the point when someone has to do the actual work. Then the project slowly fades into the background and is never heard from again. I’m not saying this happens to every project, take @Kem_Tekinay for example, he’s got several successful projects on GitHub. I’ve even contributed to them. But the overall track record here is that groups of people can’t agree on the rules, guidelines and coding practices, much less working collaboratively on a common project for an extended period of time for free. The conversion of macOSLib to 64-bit is one that comes to mind.
Look, I understand that you think this would be a win-win situation, but the fact of the matter is that even we don’t let new people just jump in and start changing stuff on their own… especially the framework. It takes time to get an understanding of how a single code change can affect the people with existing projects. All new engineers get daily code reviews from at least one other engineer who’s familiar with the code they’re working on. In the first few weeks, everything is on a branch so it can’t hurt the ship-ability of the product.
- I would immediatlely dive in and fix my top 5 bugs and offer the fixes upstream to Xojo. I suspect other top developers would do the same.
Those five things that you’d “fix immediately,” how long have they been around? Does your change affect the behavior of the Xojo IDE or other parts of the framework? Are you going to fix those things too if it does? If it’s discovered that a change you’ve made negatively impacts the product as a whole, how’re you going to feel if we roll back that change and everything that depends on it?
The framework being open source, but without an IDE and compiler, would not cost Xojo any money - the value is in the IDE + compiler, which Xojo would control.
But it sure would give a competitor a hell of a good start to create a derivative work…