If they want to distribute the contributions, they will have to make it clear up front.
(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.
Or is it a case where Github's size/reach makes them unique in this at scale?
So if its too ethical to pay for quality software, just think about your own job, you get paid, right?
Sublime is not free, still people create packages for it, for free.
Do you mean that if the code is open to everyone, the software should not cost?
Kind of weird, using open source software to create software to make money, but not being able to sell software for money if its opensource.
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.
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.
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).
https://github.com/sergiotapia/atom-darcula
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.
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.
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.
well, me.. that's why I'm reading your blog
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.
