Open Source

[kevinschaich]

I don’t think a long introduction nor discussion here is necessary. Put simply, Sublime Text will cease to exist as closed-source software.

Already, Visual Studio Code and Atom surpass Sublime in features out of the box and in extensions, despite their existence for a fraction of the time. Why this exponential growth? The power of open source.

They each have their issues, but they are maturing. Sublime still does many things better, however in a year, perhaps it will not. Sublime can hardly hope to survive on $80 licenses when its competitors have collectively nearly 6,000 reported issues, over 200 pull requests, and nearly a thousand contributors. It is only a matter of time.

We can, and would love to, help prevent this extinction. But only if you let us.

[FHTheron]

Rinse and repeat:

Author's thoughts on Open Source

What's happening

Thanks for all the comments, it's encouraging to see. re: working with the current GUI, rather than replacing it. These are all very good points, I'll put some more thinking into it. re: open source. I'd rather see Sublime open sourced rather than abandoned, but it is a commercial venture, and it just doesn't make any sense to both release it as open source and continue working on it. For interests sake, last time I counted, Sublime was around 70k lines of C++, including blank lines, comme…

Personally, I’ve been using VS Code a bit and like it, but I still like SublimeText more. I don’t consider these to be direct competitors - VSCode is almost a full IDE, ST is a brilliant and fast code manipulator and navigator. Perhaps one could call it a middle ground between a vanilla SCiTE and a full IDE.

[nblackburn]

Sublime will always be faster and personally see no issue with it continuing to be a commercial product, it’s clearly worth the investment for many developers. The only exception being the freeloaders of the internet preaching that open source is better, more secure blah blah blah completely unwilling to support financially on any level.

Better is completely subjective and It’s not more or less secure, just because we can’t see what is going on, doesn’t mean it’s riddled with malicious code.

If people were willing to support it financially then perhaps this would be possible but when ever there is an option not to way someone for the thousands of hours they have put into saving you time and making your life easier then they often wont.

[deathaxe]

@kevinschaich If you want to contribute, write high quality packages of high value and maintain them for ST’s lifetime.

The biggest issue IMHO are the heavy number of partly old and no longer maintained packages with often very tiny and special use-cases.

ST’s python API allows much things to be done. But only few seem to be willing/able to built value on it.

[BPL]

While of course I’d love to know more about the internals of ST (just for the sake of learning). I wonder which benefits could really bring to the product itself being open-source.

ST is perfectly extensive by definition and it provides a lot of flexibility to devs. I mean, of course there’s still space room to add more cool features to the core like plugin_host supporting more modern python versions, interacting with pyqt plugins somehow without freezing the host or just being able to create plugins by using another python UI toolkits, but… that’s pretty much. I think objectively speaking the ST core is rock solid and having a small centralized team planning and coordinating on top that works and it’s worked quite well for ST team and for the community.

IMHO having more devs is not gonna be always the best choice for a product to improve faster, sometimes 2/3 talented devs with years of experience in a product is proves to be more effective than thousand of github contributors without any type of coordination, in fact, that could even slow down development.

Btw, you say visual studio and atom could surpass ST eventually with some sort of exponential growth? I don’t understand what you mean here, i’ve followed VS since 2.0 version and i think is the best c++ IDE out there without much thinking but that’s pretty much, comparing it with ST is like comparing pears with oranges, just not fair… and about Atom, yeah, in this case the comparison is fair… but just to say the ATOM very foundation is completely wrong and as a result just an extremely well designed-architected slow piece of software, so… again, I don’t understand the comparison at all. Even if those products improve exponentially as you’ve suggested I don’t see myself considering them as an alternative for ST, which already has all the features i can need to code any type of project (small/medium/large) on any kind of language and being productive

[facelessuser]

People forget that GitHub has a vested interest in providing things like Atom and GitHub Desktop. It’s drawing people into their ecosystem. Atom wasn’t created to bring in money directly. And as I recall, not all of Atom is open source.

GitHub is a for profit company that is offering a free editor that they are paying employees to make. These big frequent releases are mainly in part due to the fact that they are throwing money at their employees to make this happen (and yes the community is fixing some small bugs here and there). They make their money by drawing people in and them becoming fans of GitHub encouraging them to pay for their for profit GitHub services. None of this is bad, it’s just what they want to accomplish.

The Sublime Text company needs to make money. If they open source it, what do they gain? People forking it creating small sub-communities that draw away from the main one? Encouraging more people to not buy it because they can essentially remove all nagging? Let’s be honest, there aren’t going to be many people tackling big issues. No one is hopping in to casually rewrite the text layout engine for RTL fonts etc. People have families and their real jobs etc.

Sublime has done a really good thing. They’ve open sourced some of their auxiliary stuff: syntax languages etc. I imagine those were a huge time sink that detracted from core editor work. And it is something easily tackled by the community. It has raised the quality of syntax which it turns makes Sublime look and feel better and allows jps and wbond to focus on the core editor. Win win for them.

[mg979]

Not to mention that even open source projects need some sort of funding in one way or another. VS Code is backed up by Microsoft, Chrome by Google, etc, it’s not that they live on thin air. MS Office didn’t go down just because there are open source alternatives, Linux didn’t replace Win or Mac etc, this kind of arguments is rather pointless. The point is mostly if the price is right for what you get, or not.

[MWrathDev]

Already, Visual Studio Code and Atom surpass Sublime in features out of the box

Yeah ok… read what you just wrote? Out of the box… that already implies that sublime has a level of customization which still allows it to compete with electron based editors, it just means that “out-of-the-box” they have catered to a specific niche of programmer (web dev i.e. the most popular one).

If it is merely this, then all sublime has to do to be more competitive is pre-roll a few different flavors of its installers with some integrated (vetted for) plugins catering to the different programming demographics.

They each have their issues, but they are maturing. Sublime still does many things better, however in a year, perhaps it will not.

Somehow i highly doubt it… Javascript has way too many limitations by itself before it can even approach the performance of compiled code.

Sublime can hardly hope to survive on $80 licenses

Really…

• KomodoIDE
• Jetbrains
• Adobe Dreamweaver + CC (4+ months)

There are many editors out there that are much more unreasonable with regards to price, IMHO i think sublime hits just the right balance, standalone payment for major versions with discounts to existing customer upgrades and all minor updates included.

when its competitors have collectively nearly 6,000 reported issues, over 200 pull requests, and nearly a thousand contributors. It is only a matter of time.

Somehow i dont think pointing out the number of bugs in the thousands is really the best way to make a case for OSS…

The only valid point in your whole schpiel is that the number of extensions is greater for products that have had a shorter lifespan.

That being the case perhaps the API docs may need to be made more dev friendly / easier to navigate, but that’s still no reason to go from being a commercial product to a freebie.

[FichteFoll]

Just a small note that unlike any package index of the competitors, all packages added to package control are reviewed, which makes the process of submission more involved and increases the overall quality of the ecosystem because bogus packages or duplicates are spotted ahead of time and prevented. Admittedly it may cause frustration for submitters when the package is not accepted immediately, but imho this is still a net positive process compared to having an entirely unmoderated list.

This has nothing to do with ST being open source but is just a thing that is often overlooked and that I wanted to mention.

[gerry]

Sublime has done a really good thing. They’ve open sourced some of their auxiliary stuff: syntax languages etc. I imagine those were a huge time sink that detracted from core editor work. And it is something easily tackled by the community. It has raised the quality of syntax which it turns makes Sublime look and feel better and allows jps and wbond to focus on the core editor. Win win for them.

I don’t think they went far enough. I also think some things are not as effective as they could have been.

• The default package wasn’t open sourced, nor were the color schemes, or sources like the sublime.py and sublime_plugin.py.
• The Packages repository is monolithic. It’s way too noisy.
• There’s lacking a process to get new new default packages/syntaxes into the core e.g. Git, INI, etc, aswell as little syntaxes that would do well to be in the core.

[facelessuser]

I don’t think they went far enough. I also think some things are not as effective as they could have been.

This is subjective. And it is difficult to please everyone. I’m personally okay with what they have done.

The default package wasn’t open sourced, nor were the color schemes, or sources like the sublime.py and sublime_plugin.py files.

The mentioned Py files are directly tied to releases and is part of the API. It doesn’t surprise me they only update these with releases. Even the default package contributes to the default functionality. I think they want to keep control of the basics as sometimes that stuff is tied closely to API changes etc. Just because it’s not compiled code, doesn’t mean it should be open sourced.

Even with color schemes and the default theme, I can see why they keep it closed. They want to control the default look and feel of the editor. You are free to customize it anyway you want. New color schemes are bringing in overrides. Or you can pick a 3rd party color scheme. Little would be gained for them open sourcing this.

Most companies don’t open source unless it benefits them. It’s a calculated move. Sublime gets the most benefit from open sourcing syntax, so that is what they’ve done. At least that is my take on it.

The Packages repository is monolithic. It’s way too noisy.

I’m just happy it’s open. There can always be something to complain about. Once it was closed, now it is open, and syntax has gotten so much better. I’m okay with the noise. But yeah, it would be nice if each language package was a separate repository. Then you could subscribe to what you cared about. I can understand this argument.

There’s lacking a process to get new new default packages/syntaxes into the core e.g. Git, INI, etc, aswell as little syntaxes that would do well to be in the core.

I think they like to keep it to the most common languages. I am sure you can propose new syntaxes, but yeah, ultimately they need to decide if it is worth committing to the maintenance of it. They’ve picked the most common languages and chosen to support those. I think they rely on the plugin ecosystem to fill in the gaps of what they are not supporting to keep maintenance cost down (even with contributor support).

Again, one could argue that every known language should be in the core. If I need a language that doesn’t come default, I just use Package Control. And if that one needs support, I can pull request that 3rd party package or file an issue there. And that noise isn’t added to the default syntax repo .

[deathaxe]

They’ve picked the most common languages and chosen to support those.

There are still enough default syntaxes waiting for some optimization for the new regex engine. The more languages are tight to the core the more complaints you’ll have to struggle with if one seems broken. Updates are delivered with ST updates only. Separate packages can be updated at any time.

The disadvantage of separate packages might be them to easily get lost in the high number of available packages.

[gerry]

It’s exhausting trying to discuss this stuff because there’s so many things that I think could be done better, but how these things are done matters.

For example when I talk about separating the packages into individual repositories I’m not talking about full fledged PC packages. What I mean is there would be a build of some kind that compiles the packages for the production release.

Take the current default packages. They’re deployed with each ST release. Let’s imagine they’re individual repos. The release would be identical i.e. I’m not saying they should be installable or uninstallable via PC.

But this explanation alone is not enough.

And it’s the tip of the iceberg:

• Docs should be open sourced, in fact they should be inlined in the *py and a build script (open sourced) used to generate those docs.
• The unoffical docs should be merged to the official (consolidate).
• The unoffical issue tracker should be merged to the official (consolidate).
• sensitive apis in the default package should pushed to the core
• dev apis in the default package should go into its own package (not PackageDev) and would be installable via PC.
• Delegate individual packages to Maintainers (if a 3rd party is maintaining a custom syntax, then they might be willing to help maintain that package as a default package).
• Packages should use semver-ish tags which the build script would use to compile packages for releases
• A secondary list of packages (under review for inclusion in the default list)

I’m not getting into the intrinsics of the what makes the pros outweigh the cons in the above, but I could. keep in mind that just because you open source something doesn’t mean you have to accept a changeset.

This isn’t even yet scratching the surface.

But yeah, I seem to be one of few who thinks that these things are pretty basic.

[FichteFoll]

I have a lot to say about this, but bear with me until I’m at a proper keyword.

[braver]

Put simply, Sublime Text will cease to exist as closed-source software.

[gusbemacbe]

Do you hear about MIT?

Sublime can continue as half closed-source but also another half open source.

Apple’s macOS is MIT.

MIT means a mix of closed and open sources.

[djspiewak]

MIT means a mix of closed and open sources.

I’m going to go ahead and guess that you’re not a lawyer. The MIT License is nothing of the sort. It’s literally a thin varnish on Public Domain.

Sublime 3 is already a mixture of open- and closed-source licenses. As has been pointed out, all of the built-in modes are open. Could more be opened up? Probably. Jon and Will are under absolutely no obligation to do so, though. Could all of it be open? Not if you want Jon and Will to eat.

[kevinschaich]

So many great points brought up. I think the ones that I find most compelling are “VS Code is backed by Microsoft” and “Atom is backed by Github”, as well as “Sublime is faster than Electron applications.”

As for #1: Sublime is already a fully-baked, 100% amazing, fully-functional code editor with an enormous following of users. We don’t require a critical mass to become a real thing, Sublime is already a mature product. My only thoughts concern just how much better it could get with a core team of 20 contributors rather than a team of 2 MVPs doing everything.

As for #2: Everyone claiming this is absolutely correct, native code is faster than JavaScript. I’d argue that the Electron forks of Sublime have more extensibility. How much better could we make the original, fast native code if we were all to collaborate?

[jtojnar]

Sublime does not need to be open-source but having the source available would be very nice. There are several long-standing issues that are low priority for the team but the community would very gladly come up with a patch (GTK 3 support, for example). See Unreal Engine or Fair Source licenses for an example, how this can be done.

[frou]

How much better could we make the original, fast native code if we were all to collaborate?

Textmate 2 can be the case study