The glaring ethical issue remains that the core of Atom is nonfree. From what I've read, the source code will be viewable but not redistributable and the public can submit pull requests. If this is true, it means that GitHub is intending to trick users into providing gratis labor for their product without retention of copyright for their contribution.
I think calling it "hackable" is a little bit of a fudge on Github's part, but from what I can see of Atom, it's open enough that I'm okay with their characterization. Certainly it's more open and hackable than github.com itself.
I don't think it's clear at all. There are a number of users on the IRC channel who seem to think that Atom will be open-source, including some Github employees!
(Tom Preston Warner has already stated that Atom's core will not be open source)
Absolutely clear and honest would be something lie "we intend to take your free labor, declare it our property forever, make money of it en put it in our own pockets".
No one would consent to that, so organizations use weasel words or bury it in the small print. Mostly, they just obfuscate the consequences. Especially the "property" and "money" bits.
And yes, that is a "trick", even though by some definitions they are "clear" about it. Thousands of lawyers make a good living off that distinction.
Well, if they are charging money for the thing and they tell contributors they aren't going to get paid, I'm not sure there is much more of a puzzle to solve.
Let's rephrase everything: People should be aware of Github's lack of communication before they start messing with this too much.
I'm not well versed in the nuances of software licensing. Are there prominent examples of other projects using a similar setup? Or is Github unique in this?
Or is it a case where Github's size/reach makes them unique in this at scale?
We don't have any details of the Atom license yet, but it sounds like it will be equivalent roughly to Microsoft's shared source licenses for proprietary code: http://en.m.wikipedia.org/wiki/Shared_source
You are conflating free-as-in-freedom and free-as-in-beer.
Software can be free (as in freedom) and open source while still not being free as in beer (ie, charging money).
davexunit is commenting on the fact that the Atom editor is proprietary (non-free) software, which has nothing to do with whether or not they are charging for its use.
Long answer: Some GNU projects require copyright assignment to the FSF. The most well known example would be GNU Emacs. However, unlike GitHub or another for-profit business, the FSF is a non-profit charity dedicated to free software. Additionally, there is a clause in the CLA to ensure that contributions cannot be made nonfree. I have made some small contributions to a handful of GNU projects at this point and I have not yet had to assign copyright for any of them.
The copyright assignment situation with the FSF and the GNU project is dramatically different than the potential situation that I've described about GitHub. I hope I've made things clear.
My real gripe with using web rendering isn't that it doesn't look native (the "native look" changes every year, so who cares if we deviate)... no, it's that it's slow and sluggish and resource-hungry. I honestly don't feel comfortable running Atom on my laptop.
I've not dealt with sluggish performance, while it may be resource hungry (I haven't looked at the resources it consumes, I have 16GB of ram in my laptop so what do I care) I appreciate the performance.
Vim with syntax highlighting and a bunch of plugins has been getting painfully slow for me these days, I've been tempted to play around with the threaded branches. Atom seems quite speedy in comparison.
Agreed. Even with small tasks, I've found Atom to be noticeably slower. Just as an anecdotal data point, it takes roughly a second to open a file or folder in Atom (i.e., after opening the app, the time b/w dragging any file or folder onto the icon and seeing it appear in the editor is about a second), while the same interval in Sublime is imperceptible.
I did try it on my laptop, but not for long enough to hear the fan running. However the CPU does go pretty crazy just using Chrome on my laptop, so I fear it'll do the same with Atom.
I love this editor! Instantly switched to it - now to wait for some Gophers to create some neat packages for Go.
This editor is so easy to extend that it took me three hours to learn how to tweak the UI from scratch (and I have NO Nodejs experience - dependencies are easy to install).
Everything is tweakable using CSS and that's fantastic. It's super fast as well, no difference whatever between this and Sublime Text 3 for me. Love it and will gladly buy it once it leaves Beta.
When I got my invite to Atom it definitely mentioned that during the beta period it was automatically sending feedback and that it was a feature that could be disabled.
So far Atom is not life changing for me but I do find it very useful and extensible, possibly the most interesting part is that I can already use it switching from Sublime Text 3 with almost zero issues because its so similar in feel.
I think its got a great chance to be a wonderful editor and I'm rooting for Atom (and Github) on this one, but there is still a long way to go before giving everyone a compelling reason to switch (especially those coming from vim, etc.
every chromium embedded also uses the google dns fyi. having built a chromium embedded app it was puzzling to me that there's no way to disable that(or maybe there is and i haven't found it). i don't know if that's the case here though(since it's blocked in my firewall).
in fact most of the so called privacy aware chromium builds also leak the dns information to google.
This is not deliberate practice, it's usually hidden somewhere in the code, and unless your firewall prompts you you might not even ever notice.
It's definitely slick. While comparisons with ST are obvious, I find it a touch more polished. One example is that the "find all" results page is automatically updated whenever you modify the results. So, if you replacing a bunch of text, the results are updated in real-time each time the files are saved.
Two gripes that I have so far are:
- The actual integration with GH does not work for me. E.g. Git blame does nothing. I haven't had a chance to troubleshoot yet.
- I can't open files (or even see them) if they're in .gitignore. I can't figure out how to turn this off.
All in all though, I like it so far. I'm excited that the community seems to have hopped on it so quickly with packages so it will be interesting to see where it goes.
It's a silly question to want the answer to, though. You can tell someone everything they need to know to judge something on its merits, and they'll still ask whether it's "overhyped" or "underhyped", or, I suppose, "just the right amount of hyped."
Hype fluctuates over time and between different venues (e.g. right now Atom is being "hyped" on HN, but next month it might be the talk of /r/programming, etc.) Asking whether something is worth the hype requires the author to be aware of exactly the level of hype the reader has experienced, which requires, basically, being that individual reader.
The git integration could be a lot better but I like the green or amber hairlines next to the line number that give you a real-time git diff against HEAD. Cool feature. It is a bit slow, especially when opening files, I've noticed.
Anyone know how quickly they're adding people to the beta at this point? Should I hold my breath on the invite I requested, or should I stop reading these articles that are making me increasingly jealous? :)
How long is it taking to get an invite through the normal github signup? I'd like to try this out to see if it is accessible with screen reading software although the answer is probably not really.
