In an article aptly titled "Open source (almost) everything", GitHub co-founder and current president Tom Preston-Werner writes[0], "Don't open source anything that represents core business value."
He specifically mentions two examples of what not to open source:
Core GitHub Rails app (easier to sell when closed)
The Jobs Sinatra app (specially crafted integration with github.com)
Now, I'd find the argument really stretched thin if you were to tell me that a text editor is your core selling point. Where does a text editor fit into GitHub's overarching mission?
GitHub gives away an incredibly powerful service (hosted version control) for free. While hosting it may not be in itself a considerable expense, personnel and R&D is.
They have all the rights to recover their costs in some way. At the end of the day, they are a business.
Making the service free for open source and free software was a strategic business decision. Services like github make money from private repos and a good advertisement for the service is to allow open software to use it for free.
Nobody asked them to spend their money creating an editor. It was their decision. They have been profitable for a while now and deciding to make an editor, charging for it, is not recouping costs for their existing service...
How do you know what their business plan is? They're a big boy company, they can make decisions based off of their own financial analysis. They decided that charging for this editor was more profitable for them as a company. Expecting something to be open source is like expecting McDonald's to give away cheeseburgers.
He mentioned not to opensource anything that represents core business value. A Text Editor is best set to grow when available free. Examples - VIM, Emacs, LightTable.
That said, there have been hints that it might be paid ("Atom is free till beta") and Github might try to make money through it like Sublime or Textmate.
Though I wouldn't worry much about Opensourcing, I might think twice to pay for a Text Editor - considering that there are really good free alternatives.
No. This is not the entitled attitude and people definitely do not think that GH absolutely must open source all their products.
The problem begins when you close-source a text editor. For me, this is a deal-breaker. I would not want to invest time and effort in learning a new tool - my primary tool, in fact - that won't stay for more than 5 odd years.
Just take sublime as an example. I've seen so many ST users, right here on HN, drooling over Atom, ready to jump ship. On the other hand, I do not see any Emacs or Vim users saying the same. This is because Emacs and Vim are very powerful editors[1] and there's no point jumping ship to another new and shiny editor that might no longer be there after a few years. Also, I've seen a lot of friction around forums regarding the fact that the author pretty much left ST2 entirely (bug fixes/enhancements) in favour of ST3. Also, the features of a closed source editor might not be well aligned with what the community wants.[2]
[1] I'm not saying that ST isn't powerful - it's okay. But, Vim and Emacs are far more powerful - because you can hack at the source itself and because generally a much larger number of people can contribute to the project (given that not many people are competent enough to actually do that or do not have the time) - [2] and, if you feel the editor/project isn't going in the right direction, you can just create your own fork and if it's good, people will actually migrate to your fork for better usage. And that really is the power of FOSS.
If it is a deal breaker for you go away from the deal. That simple.
And if you do not want to invest a couple of hours learning a new tool I doubt you will invest dozens of hours fixing it anyway.
This "it is not open source, I cannot hack it" sounds a lot like "I cannot change a battery on my phone any more" whining: many complain about it, few ever had a need or done that even if it were possible.
> If it is a deal breaker for you go away from the deal.
If it wasn't already abundantly clear from my previous comment, that is exactly what I'm doing.
> And if you do not want to invest a couple of hours learning a new tool I doubt you will invest dozens of hours fixing it anyway.
First, my comment was in response to the person claiming that "those not using Atom because it's not FOSS" are having an attitude that they're entitled to the editor being open-source. I was merely trying to point out the reasons why some of us expected a text editor (not any other software but specifically a text editor) to be open-source.
Second. Since you've entirely glossed over what I was trying to say, I'll explain it again (I should use easier English, I suppose).
It is evident to me that you are absolutely oblivious to the philosophy that drives FOSS. For a software to be open-source isn't important for me because I can make changes to it - it's because anyone can make changes to it. Let me put it in easier terms: If there are a large number of people using a software, and, that software happens to be open-source, it will generally lead to the betterment of the software as time goes on. Why? Well, it's because it is not at all imperative for me to change the code - in fact I know I'll pretty much never need to patch, say, Emacs - for the software to become better because I know that there are other people who are doing so - thereby leading to a better piece of code. Examples of this kind of behaviour is spread all over the place. The Linux kernel is a pretty good example. So is git. Now, because an editor is the primary tool of a programmer, you can be sure that a very large number of people are going to use it. If even a fraction of those people contribute to the editor's source, you can be pretty certain that the editor is evolving according to the needs of the community (and not according to the organisation owning the software) since that fraction of the people contributing code will represent pretty evenly the general demands of the community. So, the editor will become better over time, evolve in a way that is representative of the demands of the community and won't die out.
Now, I'm not saying that Atom isn't a good product. Indeed, from the looks of it, it appears to be a very well rounded text editor. But again, it's not open-source and hence, the benefits that I talked of in the last paragraph won't apply to Atom. This means that the project might die out in 4-5 years. Then, there's the fact that Emacs can do much much more than Atom right now and I expect Emacs will be around 20 years from now [1]. These facts lead me to the obvious conclusion that there is no incentive for me to switch to Atom. Had Atom been open-source, then, it being a pretty great editor already, I know that it would have been much more likely that Atom would still be around 10 years from now (Why? See the last paragraph!). Then, I might have made Atom a second (actually third, second is Vim) editor that I'm proficient in. But alas! That is not to be.
Anyway, I truly hope that you understand why it is that I (and many others like me) want the text editor to be open-sourced. It's not because I will make it better - it's because I know that there are others, far more competent than me, who will, and, do so according to the wishes of the community using the software.
[1] Extrapolating from the fact that it has been around for 20 years already.
GitHub is based around open source software. Ruby on Rails, Git, various other tools in deployments. Working inside open source browsers mostly. Breathing the open source community on its site.
For me, GitHub is an open source company even if they don't open source all of their code...
I don't equate git with github, I just don't like bloating my posts with too much nitpicking.
A ton of companies are based around open source software. That's kind of the beauty of it. It has enabled the proliferation of businesses and has sped up innovation.
But by your logic, the NSA must be an open source government agency. After all, the Snowden leaks revealed that their technology (including XKeyscore) is built on open source software.
"Working inside open source browsers mostly."
Every website and web application is open source now? If you can find a way to arbitrarily lift server-side code from any web application, you'd be hailed as the next technological messiah.
No, GitHub using open source software does not make their platform open source. They do give back to an extent, sure. But that's hardly anything to celebrate by itself.
I did not say their platform is open source. I did say instead that the character of their main business puts them firmly in the open source space. Not even counting their own github account with open sourced software they created...
It's an entitlement because developing something like this requires an absurd amount of time and money. Why should they work for free. Do you work for free? Would you consider your boss entitled if he expected you to work for free?
What's my view of OSS? I'm thankful for it. Yes, it's free work - they're working (although doing it for pleasure) and giving it away as a gift. I guess that's the difference, I view it as a gift, others seem to think it's immoral to work for pay.
Edit: Please enlighten me, what exactly is immoral about charging for software that takes thousands of man hours to create?
I don't get what point you're trying to make. Is it wrong to sell software that has some piece of open source in it? It's not like they cobbled a bunch of open source projects and placed a license check on it. Do you realize that virtually every application uses some open source library?
So what's your view on Open Source/FOSS projects where people contribute and write code and share it for free without asking for retribution ? Do you consider that "free" work ? Don't you benefit from that anyway ?
Open source isn't about working for free. It's about pooling resources in the community to provide a baseline from which competition can begin. Open source improves the efficiency of the overall system, allowing innovators to focus on innovation, not basic functionality (like operating systems, text editors, web servers, web frameworks, programming languages, virtual machines, etc.)
Google sells advertisements, so they make a free browser that makes the web fast and secure. They improve search to make the web more useful for everyone. They help get third-world countries online. Why? Because when the internet grows, Google grows. They're not working on search "for free".
GitHub might have taken a similar view with Atom: by creating a freely-available, polished, advanced, and easy-to-use programming environment, they might help foster the growth of a whole new generation of hackers that would use GitHub to easily store and share their code, right there, baked into the editor. Universities might pick it up, and it might be featured in coding academy curricula. Student projects might involve writing plugins for it, extending it, and making it their own: often the first task of an artisan is to make and customize his or her tools of the trade. And GitHub would be there, at the center of it all. Rather that some advanced hacker tool shrouded in mystery, GitHub would be built-in to every new coder's first experiences with programming: an iconic brand synonymous with that eye-opening rush of seeing your code work for the first time.
Open source isn't about entitlement. It's about making core building blocks of software available to all because everyone shares an interest in those core pieces, and it's cheaper/faster/better to work together on shared code that doesn't contribute to market differentiation than mucking around trying to build an maintain a bunch of secret, closed-source code that everyone is going to need anyway. Open source frees up resources to solve more interesting problems.
Editing text isn't a particularly interesting problem: the best models for it were developed decades ago, and the main innovations since were fonts and color themes. Text editors are a prime candidate for open sourcing, and most good ones are, including huge IDEs like Eclipse, Netbeans and IntelliJ. To say nothing of Emacs, Vi(m), nano, mg, TextMate, LightTable, Brackets, Notepad++, Kate, GEdit and dozens of other sophisticated, open-source text editors.
Expecting GitHub (of all companies) to err on the side of closing up the source for a text editor (of all products) seems strange.
> What? I just started learning Ruby, and I intend to do some sys-admin tasks also. Am I going down the wrong path?
I don't think so. Ruby has for me replaced bash scripting along with sed, awk, and Perl. It's nice to do all these things with one consistent syntax. And be sure to check out Pry (http://pryrepl.org/)!
That's kind of a stretch. Bash is the only lingua franca of devops. Perl might be next, depending on the organization you're involved with. Then Python or Ruby might be next... hard to even figure out how to objectively measure which of the two is more popular in the "devops" space.
you're not, ruby is an excellent sysadmin language. python has the edge for scientific computing, though, due to the larger base of people using it for that. also pygame is great.
yes, well, mostly. python has subprocess.Popen which is an awesome way to call out shell cmds, but I do most of my SA work in ruby. I just find it more pleasant to write.
I don't think there is something inherent to either language that makes it more or less suited to sys admin tasks. Python just happens to be used more often for this. Many Linux sys admin tools (GUI and non-GUI) are written in Python (PyQt/PyGTK). yum, HP printer tools, firewalld, the setup tools of many distributions, dtrace, iotop, anaconda, mercurial.
Python is stricter and more explicit. Ruby has many convenience functions that I consider messy and some even dangerous. E.g. Ruby supports the same ` `-Syntax as the Unix shell, with all it's implications.
Yes, it's more to write but it's more powerful and you don't have code injection problems. It feels to me that Python encourages you to do the proper clean thing while Ruby tries to be very concise and quick.
Also compare regular expressions.
Ruby:
if "foo" =~ /f(oo)/
puts $1
end
Oh my god, it assigns a global(?)/magic variable as a side effect. Yes, there are other ways to do it and when I write Ruby code I am using these other ways, but when I see other peoples Ruby code its done like that. I do this:
match = /f(oo)/.match("foo")
if match
puts match[1]
end
Python:
import re
match = re.match("f(oo)","foo")
if match:
print(match.group(1))
If you evaluate the regular expression more than once you should compile it:
import re
regex = re.compile("f(oo)")
match = regex.match("foo")
if match:
print(match.group(1))
Again in Python you tend to write it the clean way. Of course it's possible to write non-clean Python code and clean Ruby code, but the culture behind the languages encourage different things. You will find a lot of Ruby libraries/frameworks that extend (monkey patch) standard types. While this is also possible in Python (for non-builtin/-binding types) it is usually not done. Look at JavaScript: Prototype monkey patched a lot of standard types and messed up a lot. jQuery learned from that and tries not to monkey patch anything.
Another issue is string encodings. Note that what I write here applies to Python 3. It's a bit more complicated/less clean in Python 2.
The idea in Python is that files/network streams etc. are binary data and thus somehow encoded. But you as a programmer don't care about encodings, you want to manipulate text (or sequences of unicode code points). So you read bytes and decode them into str(ing)s. After you are done processing the text you encode with a certain encoding again and write the bytes into the file/network stream. So there is the bytes (and bytearray) class that has a decode method and there is the str class that has an encode method. str objects are always valid unicode codepoint sequences. Encoding errors can only happen on decode/encode.
In Ruby there are only Strings. These strings have an encoding attached. Binary data has the "encoding" ASCII-8BIT. You can force a wrong encoding onto a string which will cause an InvalidByteSequenceError at some later point. If you try to concatenate two String objects that have a different encoding you will get a CompatibilityError. You can only hope that all your DB drivers return proper UTF-8 strings in all cases. I was told even Perl does this better (like Python).
Furthermore in Ruby strings are mutable, in Python they are immutable. This means if you get a string passed in Ruby and want to store it in a classes attribute and want to be sure it does not change under your but you have to make a copy.
So you can clearly see what language I think is cleaner.
I write Ruby code for work but when I write some shell script to automate some task/write some small GUI tool I use Python (and PyQt).
Yeah I know it's a local, but it reminds me of other languages where it's global (JavaScript). It get's confusing. And even as a local it is still bad. How is it that the =~ operator can assign local variables? Can other method calls do the same? If not, why not? Why this special status?
> it reminds me of other languages where it's global (JavaScript)
Ew, I didn't realise JS had them and implemented them like that. It's supposed to remind you of Perl, which probably made more sense 20 years ago.
> It get's confusing. And even as a local it is still bad. How is it that the =~ operator can assign local variables? Can other method calls do the same? If not, why not?
Actually, they're not locals, they're "virtual variables", going by the code. You can make your own using the C API - they just call back into a function:
There is someone who cryptically mentioned, I think on the thread about measuring a startup's product viability by whether or not employees voluntarily used said product, being a developer for Opera and his management team alienated a lot of developers by blowing off Linux and denigrating interest in it as a platform with supporting and the general low blow jokes.
I am too lazy to search. Maybe you or someone else will point you in the right direction.
I live in India, and I face the same situation time and again, which you are facing now.
I've come to a conclusion that it's because of Hacker News, the more you see HN, the more you get worried by watching a lot of start-ups growing in front of you, and you can't do nothing but press an upvote button, applauding their success.
What you need to do is close HN and minimize the time you spend on it, instead work on something, start small and don't get depressed easily.
The stories you see on HN are months hard work, they also feel same time and again, but they don't lose hope.
I know my comment is bit harsh and not sympathetic, but IMHO right now you don't need sympathy instead you need motivation.
I sometimes wonder, can cloud IDE's will really be able to replace traditional code editors like Sublime Text, Vim, Emacs.
I really like the idea of cloud IDE's, but practically it's difficult to bring the entire development environment on cloud/browser, and even more difficult when switching from Vim.
Anyways, I really appreciate the efforts you are putting in this project. Congrats guys/gals, job well done.
What advantage do you see versus just the ability to edit remote files (which has been around for decades) or sync local files with a server (a.k.a. "cloud storage")? Why suffer the UI limitations (solvable), latency (not solvable), and unreliability (not solvable) of having your development environment sitting on a server somewhere?
I find my self writing code in VIM via ssh using tmux and works fine. You can do pretty much everything on CLI, so I don't see how this is a substitute for VIM when all you need in order to write VIM/emcas code is a remote (secure) shell.
That said, vim is not an IDE, although many prefer (me included) prefer it over an IDE.
I have the same reservations. There are a few notable developers who have blogged in the past abut using Nitrous [1] as their primary development environment, so I'd like to say it's possible.
I wonder though if something like Vim.js [2] couldn't start to get closer to making this a practical tool for my workflow. Between that and having offline support / native app to use, there'd certainly be a lot of benefits. Ultimately though, I think the #1 thing it'd come down to is lag; if there's lag (like ever, including trying to launch the program, when I'm offline, or while I'm typing), it can't be my primary development environment without constant annoyance.
Codebox will actually be released as a desktop app as well. And I think that's going to be pretty important to have a truly hybrid IDE that runs both on the desktop and in the cloud.
And what's particularly nice is that the cloud IDE and desktop IDE can share 95% of their codebox.
As a result you have an IDE built with web technologies (JS, HTML, CSS, NodeJS) that can run virtually anywhere (desktop, public/private cloud) and you can iterate quickly thanks to the nature of web technologies.
