A Modest Proposal

General
1

Xojo (the company) is in a weird state: big enough and successful enough for some things, but at the same time too small and under-resourced for others and really struggling. Basic features remain broken for years, unit testing coverage is poor at best, new platforms are delayed and old platforms suffer, etc.

(I assume most developers here would agree with this assessment, but if not, happy to provide more details as to my opinon)

To be fair to Xojo (Inc) the software environment has become increasingly difficult: many OSs having frequent changes and an increased focus on security has made making software very hard. I feel this as a (very tiny) app developer. I spend 85%+ of my dev time just keeping up with (mostly) Apple and (somewhat) Windows changes and bugs, and less than 15% on developing new features.

Open Source software (and the “in-app-purchase”) model has made it hard to sell software. Open source has driven the modal software price to $0. “In app purchases” have helped suggest software is free (though it’s a lie). Many corporations have adopted the “how much you got?” pricing scheme where their software is free (if you are broke) but $$$$$ if you have money. This is particulary hard for Xojo’s “citizen developers” (their term, not mine) who simply want to make a few $ selling their unique and (often) high qualty but low volume software.

Here’s my proposal:

  1. Xojo should open source the application framework.
  2. Xojo should not open source the IDE or compiler

Why?

If Xojo were to open source the framework:

Pros

  • 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.
  • some plugin makers might do the same(?though see below?)
  • Xojo Inc. could devote less time to the framework and more time to the IDE.
  • 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.
  • Xojo (and many of us) use a lot of open-source software - it’s prudent and ethical to give something back to the community.

Cons

  • Managing open source software is not zero cost - Emotionally, Xojo would have to make a big change in abandoning the “NIH” (Not Invented Here) syndrome - a culture shift. Fiscally, Xojo woud need to devote some staff time to managing pulls and reward this appropriately.
  • Plugin authors might lose income? (if they decided to add their features to the framework, rather than selling plugins). However this would be up to them. Maybe Xojo could fund plugin developers who opt for open source?

I’m proposing this mostly seriously but also somewhat as a hypothetical for discussion – I, too, have a copmany that uses fully closed-source development, and I’ve seen dramatic market changes in the past 30 years, and I’m interested in new(er) business models.

7 Likes
2

Interesting proposal but… You are talking about openning source code to a company that thought changing the sintax just for the sake of change instead of fixing bugs is an improvement :expressionless:

6 Likes
3

does open source mean that there are a thousand versions and dozens of forks? go crazy behind GitHub and stuff? personally no, thanks.

3 Likes
4

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…

12 Likes
5

Shouldn’t Xojo care for the customers good in the first place and only second think about how could this also be good for the company?

If the customer is happy, you’ll find a way to keep the company happy.

1 Like
6

This is how OS-projects work. It’s a mind shift, no question.

I assume that you’ll be able to review more foreign written code, than writing own code. Also: you guys would really work on things which are important to community. In the end, you become one part of a huge team. Your work would change, but the outcome also.

1 Like
7

Sorry but this proposal doesn’t seem modest to me. Open source my main product source code and let others do what they want with it with no additional income? Er - no thanks. Why should they? Xojo has its issues - so does any other dev tool. I use Visual Studio 2017 in other work and it crashes and hangs regularly. The Xojo IDE does not. I have used Xojo for many years and the range of app opportunities it brings on different platforms far outweighs its defects, the vast majority of which can be worked around or a respectable plug-in used instead.

14 Likes
8

I did not get the bit why plugin authors would be pushing their things into the framework.

Its not like Telerik pushes their controls into NET framework even if NET framework is open source.

1 Like
9

The resource concern of Xojo is certainly a question in regard to agility, time to market, even if the team is bringing heroic efforts to bring new features and correcting bugs. My concerns are

  • the nurturing of a more cohesive eco-system. A more visible and central repo of xojo lib and packages would help. See PyPI for Python, Packagist for PHP, Rubygem, Crates for rust, …

  • some of the dev. priorities (but Xojo is a private company, so customer feedback con only help to a point)

To get more speed, instead of open sourcing the whole framework, why not experimenting with a prt of it and try to build an established community of reviewers. There are several possible workflows.
Some open source communities bring remarquable quality products (postgres for an example). But often, there is enough commercial backing (with business leveraging the reviewers, coders work).
The main point here being more agility and quality.

1 Like
10

If I’d have the chance, I would probably make fixes on behalf of clients to the framework and push them back. But that has of course some copyright and liability things to figure out.

2 Likes
11

Open source is not the answer that is for sure - like Greg said above these all start off with good intentions but it needs commitment alongside your normal work activities. I have seen so many example of open source failure - look at LiveCode who raised tens of thousands of pounds from their user base in order to setup the structures required to open source their code base.

They found that the contributions had an initial flurry then died off to virtually non existent meaning their engineering team had to then maintain two code bases. They found that what they hoped would happen with the open source users in that they would go on to purchase licences for the additional functionality in the paid versios. It never happened and many users stopped purchasing licences and stuck with the open source version.

LiveCode last month decided to remove the open source platform and revert to the licensed model only. This caused angry messages from the user base but what choice did LiveCode have - let the users have a free ride but never pay anything?

I appreciate what has been discussed is slightly different in structure but many of the challenges are the same.

Open source is not a panacea to solve all resource constraints.

4 Likes
12

The SQLite team has this issue too (since they have to be able to guarantee that their whole code base is in the public domain). So although they “accept” patches, they re-write them from scratch.

13

Really? Last year, my open source app made more money than my full time job.

6 Likes
14

I would like t o see Xojo Inc. hiring more tech-staff in order to develop faster and have more resources on quality control. Too many things are being developed at the expense of quality and long time known bugs.

15 Likes
15

Exactly this. This can even go at the expense of the people behind it.

16

perhaps the services correlated?

17

I don’t offer services.

18

To use a specific example: I’d fix 54638, the bug where String.Left() returns the wrong length string on Asian language systems. Since it’s clearly a bug, and has sat in “Verified” status for 2.5+ years, and is costing me money, I would spend time fixing it. Also, any side effects that happened would be a good thing: if broken code is fixed, and breaks other code, that would mean it has revealed bugs in other parts of the IDE that needed fixing, too.

Many parts of the Framework are nicely encapsulated and bugfixes like this generally should not cause any problems.

Are there parts of the Framework that are not encapsulated, where a fix would be more risky? Sure.

If Xojo kept the IDE and Compiler closed source, I fail to see how this would be of much value to a competitor.

Right! I chose the title on purpose: :sunglasses:

2 Likes
19

It sounds like they open-sourced their entire product? Not what I’m proposing here.

Can you share your business model? Is it open source (free as in beer) but people pay for a support contract? It sounds like Xojo (inc) is afraid that “open source = $0” (a fear that many of us share)

1 Like
20

Open source doesn’t mean “for free”. Xojo needs to keep it’s financial basement. We’ll always need to keep good engineers like @Greg_O_Lone working on it full time.

But I am pretty sure, that well guided OS projects can be super successfull (there are plenty of good examples).

It is only about gaining more manpower for the project. The work of the Xojo team wouldn’t change neccesarily so dramatic as described. Also the additional amount of work for going through merge request and such could be guided by the community (look at the MVPs or @Paul_Lefebvre as former evangelist).

Opening the framework could help fixing bugs.
Opening the IDE (not the compiler, mostly the UI) would help to make the IDE a more modern tool.

I am sure it could be an opportunity. But I am also sure, that the current Xojo Inc. is not able to make this shift. Not able due to their philosophy, due to their structure and the leadership. And frankly this is okay. It’s their choice, and we have to decide whether Xojo is the right tool for us or not.

1 Like