Why Kreya isn't open source

&gt; And even if we created or found an applicable license, who would enforce it? We are a small team of four software engineers from Switzerland and we have neither the knowledge nor the means to report license violators.<p>Everyone who goes &quot;just release it under XYZ license&quot; misses this one key part. There are next to zero examples of small companies successfully enforcing their software copyright. It is expensive and takes a team of lawyers to do so.

I&#x27;d like to see source trusts like the code is given to an authority that will make it Apache&#x2F;MIT&#x2F;BSD if conditions are met. Let the creators draw the line in the sand. Company goes bankrupt. No new release for 3 years. Or maybe always release the code from 5 years commit by commit. Just to prevent abandonware and lost sources. Should be sufficient to preserve commercial viability.

We are having a similar discussion for the startup I am working on (Caido.io). We are bootstrap and would like to make a living out of our work. We just don&#x27;t have the luxury of VC money where we can open source and worry about making money later.<p>Our compromise is that we are open sourcing anything that is not the core of the application for now. If we have enterprise &#x2F; cloud features down the line, we will open source the core.<p>I would really like to live in a world when open source doesn&#x27;t necessarily mean gratis or direct copy by a competitor, but I have yet to see that work for desktop applications.

&gt; Once you open source a project, it is out in the open.<p>Gitlab disproves this.<p>E.g., they have no solution on the horizon for dealing with spam for their open source Gitlab Community Edition. That means that for common use cases like having an instance open to the public for participation in GSoC, a gitlab-ce instance will get eaten alive by indonesian casino spam (or whatever the current spam offerings happen to be).<p>But they <i>do</i> have a solution for their proprietary Enterprise Edition which uses a proprietary blob. One of their employees suggested I just switch to that version because it&#x27;s apparently available free of charge.<p>The other possibility is to use whatever they run on their gitlab.com service. In that case it&#x27;s not my instance so the license doesn&#x27;t really matter as much. Nevertheless, I&#x27;m almost certain they are running their proprietary spam filter there so it&#x27;s not open source either.<p>In conclusion, this is a perfect refutation of the author&#x27;s point. Start open, run a service that&#x27;s free of charge, and slowly cut off the flow of key features to the open source version (or simply do not care about that flow).<p>Edit: clarifications

It seems like more and more companies are doing this. Kind of concerning. Is true FOSS going to fade away one day?<p>Chromium no longer has sync, so we currently have <i>no</i> usable browsers that support Google&#x27;s stuff.<p>The last 15 years of open source progress seems to have been driven by big companies rather than the community.<p>Community driven FOSS doesn&#x27;t even seem like a reasonable idea at all given how much work it is, and how completely thankless it is, so most of what we get there is just &quot;scratch your own itch&quot; type stuff, often fairly useless outside a really specific use case, rather than the real pro-grade packages.<p>Arch seems to be eating some of Debian&#x27;s dev base, and Arch is built from the ground up for highly customized &quot;just enough&quot; setups.<p>It seems like the community mostly just cares about privacy and tinkering these days.<p>What&#x27;s going to happen to the &quot;Windows-like&quot; side of FOSS?

Personally I&#x27;m a fan of MariaDB&#x27;s &quot;Business Source License&quot;. Enough of the benefits of open source that I can trust your product, but enough of the benefits of closed source that you can use whatever monetization strategy you want.<p>It seems like a pretty good compromise to me.

Most relevant part: &quot;With the upcoming 1.8 release of Kreya, we plan to include a paid version&quot;.

I wonder - would it be a good idea to release the source code a few versions old? Competitors likely already have implemented similar things so no major corporate issues. Not open source, just source-available, so no issue with Amazon running off with the code. And power users&#x2F;fans can add their own additional software which likely will still work with newer versions.<p>Of course, I&#x27;m likely missing several things - I&#x27;d be grateful if someone could point these out. (I&#x27;ve been thinking of this strategy not just in this specific case but in general.)

The &quot;we want to make money&quot; argument is pretty weak when desktop software like Ardour demonstrates that it&#x27;s still possible and feasible.<p>The &quot;we don&#x27;t want to be stuck with a too-permissive license&quot; argument is also pretty weak when there are a <i>lot</i> of licenses besides MIT (and when they, being the copyright holders, can relicense at any time; sure, the cat&#x27;s out of the bag for already-released code, but for future versions that ain&#x27;t necessarily the case).

There&#x27;s open source backend software and there&#x27;s full-stack &#x2F; GUI oriented software and in my limited experience, I don&#x27;t think the latter always makes sense.<p>Smarter people than me have articulated their points about that:<p>- <a href="https:&#x2F;&#x2F;blog.wolfram.com&#x2F;2019&#x2F;04&#x2F;02&#x2F;why-wolfram-tech-isnt-open-source-a-dozen-reasons&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.wolfram.com&#x2F;2019&#x2F;04&#x2F;02&#x2F;why-wolfram-tech-isnt-op...</a> - <a href="https:&#x2F;&#x2F;macwright.com&#x2F;2021&#x2F;12&#x2F;07&#x2F;sharing-in-the-presence-of-computers-and-corporations.html" rel="nofollow">https:&#x2F;&#x2F;macwright.com&#x2F;2021&#x2F;12&#x2F;07&#x2F;sharing-in-the-presence-of-...</a><p>&quot;Placemark, the application, won’t be open source. I didn’t even consider the possibility: open sourcing the application layer of a product just doesn’t work. You get all the downsides of community support, white-labeling, process friction, confusion around why people have to pay, confusion around whether to use the open source version or the paid version, and none of the benefits.&quot;<p>I think the dream is to open source the standards, protocols, backend engines, etc. But man, whenever you have to think heavily about a user interface, things get really hard. How do you decentralize design of something?

Here&#x27;s a possibly novel take – the modern interview process for software developers is causing more and more projects to move to these non-FOSS licensing terms.<p>&quot;Wait, what? What could convoluted interview processes possibly have to do with licensing?&quot;<p>Well, developers need to make money <i>somehow</i>. In the past, releasing your software as FOSS allowed you to display your skills for software development and feature planning out in the open. Often, you&#x27;d be hired on the basis of those demonstrable skills at a paying job even if you didn&#x27;t make money on the product itself. Multiple engineers I know went through very abbreviated hiring processes, being pretty quickly waved through if they had worked on FOSS in any significant capacity.<p>Today, that&#x27;s not the case at all, and any interview process for a high-paying job seems to have 5-6 rounds of arduous interviews, no exceptions. I have conducted around fifty or so interview processes for dev positions at a non-FAANG company, and &quot;look at the candidate&#x27;s FOSS experience&quot; isn&#x27;t on a single one of them. I don&#x27;t think I could get any major FOSS contributor exempted from a single interview process at my company on the basis of their experience. The case of the Homebrew creator and Google is reasonably well-known [1].<p>Well, the natural response is going to be for them to work on their own product, and not open up the source code unless they get paid for it. Which is what software devs are doing these days, in increasing numbers.<p>----------------------------------------<p>[1] <a href="https:&#x2F;&#x2F;twitter.com&#x2F;mxcl&#x2F;status&#x2F;608682016205344768" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;mxcl&#x2F;status&#x2F;608682016205344768</a>

I like the idea of a promise that all code will be open sourced at a 2 to 3 year delay. I have seen this model in use, and it disincentivizes competitor forks (especially if that open source is GPL) while still allowing paid versions.

I don&#x27;t see why there&#x27;s a need for this explanation. If your end goal is to sell the software you make you shouldn&#x27;t open source it.<p>The main use case for open source is software you USE, you release it into the wild so others also add to it and it becomes better for everyone to USE. See programming languages or frameworks. You&#x27;re not selling the OSS, you&#x27;re getting others to improve the OSS that you then use to create a closed source product.<p>Open sourcing software you intend to sell means it&#x27;s either a trojan horse or someone else just sells it (in one case dishonest, in another case you get exploited).

It really seems they&#x27;re trying to get things right, but are afraid of the competition. In my opinion this is because the company and the product is new to the market. Once they know that their income isn&#x27;t tied to them being closed-source, they might change their position on this, or they will keep their customer locked-up because they&#x27;re afraid of them running away.<p>This seems to be missing the point : Freedom for the users on one side, and sharing knowledge on the other side.<p>Here you have neither of the two and the only reason is fear. If your startup isn&#x27;t successful and you have open-sourced your code, it&#x27;s probably not because of the competition using your code, but because you&#x27;re not solving a problem that people need to be solved.

For an app like this, open sourcing non-business-critical parts of the app a perfectly valid way to go about it, like they are doing with the templating library. You still get visibility, testing and the occasional bugfix from the community.<p>Another possible way to go about it is open-core: Open source version, with more advanced features on a closed-source solution. Contributors to the open source version have to waive off some of their rights in order for this to work, though. There are tools that automate most of that these days.

I wonder if a nice source available license comes about, similar to how we have common ones for FOSS like MIT which are well understood and easy to apply.<p>A source available license allowing for personal modifications, sharing with other licensees, contributing fixes that might not be a priority to the dev is present with projects like Unreal Engine and a few other examples I can think of. However they are all bespoke licensing.

&gt; Desktop apps are a special case<p>As someone who remembers when most apps were desktop apps this seems a strange point. I suppose it&#x27;s a better look than what the actual header for this section should be which is &quot;we want to sell this for money&quot;

I respect that they have reasons not to release Kreya as open source. Fine.<p>But claiming &quot;We love open source&quot; is a blatant lie: the article makes it really clear that they only love the aspects of open source that are to their advantage. They should better honestly write this.

TLDR: Money

&gt; First off, we are huge fans of open source projects.<p>This one sentence makes the whole post come off as disingenuous to me. Who isn’t a fan of free work?

This should be titled, why Kreya doesn&#x27;t actually understand or believe in open source.

&gt; First off, we are huge fans of open source projects. For example, Kreya uses the open source scripting language Scriban.<p>I really don&#x27;t know how you overcome to cognitive dissonance to continue after this. Call me naive, but it&#x27;s pretty scummy to take someone else&#x27;s open source work, add some extra code, and slap a pricetag on it.<p>Also doing that violates most copyleft licences.