> Don’t you just hate it when you find some great piece of code on GitHub and then you realize that somewhere at the end of the README the frightful acronym GPL is ruining your good mood?
Yes. But what I ‘hate’ even more is not finding any license info. Adding this would probably help in that area as well.
I know that personally, I've relicensed code to be more permissive on request. Of course, you have to ask, but sending an email might be less work than writing your own version.
I've done this twice with GPL code, when I was writing a library and/or library bindings that I specifically wanted to be available for use by all developers, including those working on proprietary products. Both times I've been turned down. One of them was a abandonware. Great C code that the author explicitly disowned. Now it will bitrot.
On the other hand, I have asked several developers who released code without a license if they would mind licensing their code under a permissive license, and each time they have been glad to do so.
The downside is, of course, that you probably need it at the time you come across it, so time wise I often have to roll my own in these cases. That’s why I hope this would make that more clear.
On that note, we need this for gists as well (maybe even more). Could be on an account-wide basis in my case.
Honestly, I don't know. I'd suppose it depends more on the sort of thing we're talking about than anything. If it's something like "Obtvse", or a fully formed system and you're copying it outwardly, then probably yes.
If it's a ilbrary that fetches RSS feeds as part of a larger system, I'm guessing no.
Of course, it also depends significantly on the author. If it's a public git repository, one assumes that it's something people wish to be forked.
Though I suppose an interesting experiment would be to publicly post closed source code with a closed source license attached as honeypots and sue everyone that forks / modifies your code base.
I suppose you could write a license that allows others to view and copy your code, but not make any modifications, as fork doesn't seem to be defined to include modification.
That’s what makes it so annoying, though, the fact that we _know_ they probably meant to share it as free software.
My point goes further than people forgetting to add a license, though. Some people think that just adding it as an open repo to GitHub is enough, which, depending on the country, it clearly isn’t.
In my opinion, GitHub should educate people a bit more about this. A simple feature like this could just be enough.
My response wasn't meant as harsh, it just lacked a smiley ;)
I work on a lot of OSS projects and our company does consultancy. This means I browse other’s projects on a daily basis (i.e. I don’t know the filenames yet). That, combined with the fact that I have a deep love for GUI design and platform consistency, has made me come to the conclusion that something like NERDTree wasn't working for me. I tried to keep on going for a few more weeks, but in the end I decided that writing a file browser would cost me less time than I lost during these few weeks.
I’m glad I wrote it, because now I’m perfectly happy with my MacVim setup, which I wasn't before. I’m also very glad I did not decide to revert to using TextMate or any of the other new closed source editors.
To conclude, it’s a bit of a feeling-thing. I’d invite you to try it out for a while to see if it works for or against your flow. No hard feelings either way :)
PS: It might not be apparent from the article, but the browser provides a few more functions that os x users might be used to in other apps. See the last screenshot: https://github.com/alloy/macvim/wiki/Screenshots.
I think I will give this a try. Thank you for writing this and taking the time to release it.
Browsing codebases that I am not familiar with is the exact use case for me. For navigating my own project, I do fine with MacVim + Terminal + "mvim in new tab in existing window conf" [1]. But for exploring an unfamiliar codebase, it's too cumbersome.
---[1]---
alias mvim="open -a MacVim.app"
In MacVim Preferences set "Open files from applications" to:
"in the current window"
"with a tab for each file"
Then, in Terminal you can do, "mvim file.ext" to open file.ext in a new tab in the existing MacVim window (or new if no window).
A lot of people miss the issue of browsing through projects that you aren’t familiar with. Auto-completing/fuzzy matching takes more time than actual browsing in such a case, because you’re probably guessing half of the time. Maybe it’s just me, but I find that to be annoying within a minute.
The reason that people use (mac)vim is not necessarily the ‘powerful navigation keys’ etc. For me it’s the ability to deal with large files and the crazy indentation rules people use and I know it’s the same for quite some other users.
The way people work differs from person to person, the idea that someone should always just keep on trying, even if something doesn't feel right, is in my opinion useless. The real moral here is that people should accept that everybody is different and that it’s ‘ok’ for them to be different and how great it is that open-source software such as vim enables them to do so. Something that’s unfortunately always a bit harder for passionate users. (No insult intended!)
I definitely know that _I_ prefer to browse a project with a GUI that works like in the rest of my platform of choice, but I also know I’m very different from the average vim user :)
Agreed - this is pretty much the only reason MacVim lives on my machines. It handles huge files way better than anything else I've tried.
I can use vim. I know it pretty well. But the inescapable fact is that, for me, it's clunky and requires more thinking than just using a mouse and pointing at something, then typing what I want to type. I use it because I haven't found something better (and I'm sure it exists, I just haven't seen it).
