▲ 256 points
back
58 comments
> Aside from the fact that much of the code that was “released” was sub-par, the very act of putting code out into the world implied (whether intentionally, or not) a willingness to participate in a social contract with those who chose to use it for their own purposes.
Not to disparage the 100:10:1 method, but I do disapprove of this implication. I don't want people to refrain from putting things out there, just because they don't want to feel obligated to support them.
I have a public blog, where I try to maintain quality, and a semi-private blog where I try to allow myself to post stuff I'm not sure about, stuff that's not interesting to anyone other than me, stuff I don't necessarily want associated with my public persona, and so on. I know others do similar things.[1]
I think there's no particular mechanism to do that with open source, but it might be valuable. Perhaps I could have two github accounts, one where I'll put anything I feel like, and one where I put stuff I'm proud of and want to remain proud of. If something's on my "real" github, I'm saying that if you ask for support I'll try to help you, if you report a bug I'll try to fix it. If it's on, let's call it my shithub, there's no social contract. Take a look if you want, and feel free to report bugs, but I might just say "yeah, that's a bug". Or even just "not interested in that project any more, I'm not going to bother confirming this".
Then, if you want to follow this method and also want to make most of your code public, you can write down the 100, put the ten on your shithub, and publish one to your github.
[1] E.g. http://slatestarcodex.com/ versus http://slatestarscratchpad.tumblr.com/
You may disapprove, but the belief that "you should only release what you're willing to maintain" is still there, and broadly held by leaders and shakers in our community.
http://blog.codinghorror.com/responsible-open-source-code-pa...
"As Markdown's "parent", John has a few key responsibilities in shepherding his baby to maturity."
https://plus.google.com/+TomDale/posts/CkmmbjmvebM
"And if you release, don't release more than you can realistically maintain."
https://opensource.com/business/11/7/responsibility-open-sou...
"open source project leaders [...] have an on-going responsibility to make it easier for community members to contribute"
The Markdown story is out of context: the issue was not John's alleged lack of involvement in the project per se, but the fact that he disapproved of other people doing so under the same name. Im not sure if it ever came to a trademark threat, but he definitely wasnt happy.
That is not what was being discussed, here.
I'm not sure I disagree with those specific examples as much as it may seem.
I do think that if you're not shithubbing, you have a level of responsibility which perhaps[1] Gruber and TJ (the maintainer in the second link) weren't taking. And it's not clear to me how much you can claim to be shithubbing if you have lots of users and are discussing the project direction and taking pull requests. (It looks like TJ has since handed over maintenance of n to someone else, which I'd say was the right decision.) The third link also seems to be talking mostly about projects which can't be described as shithubbing.
The main thing I want to get at, is that you should be able to put something online without having to take responsibility for it. (Perhaps we need to distinguish "online" from "released".) That doesn't mean you never have any responsibility.
[1] To be clear: I don't know much about these two incidents, but the actual details aren't particularly important right now. I'm discussing them to bounce intuitions off them, not to pass judgment on anyone.
You can start on github just by being clear what sort of repo you have in the readme. There's all kinds of projects on there, from "I accidentally the fork button" to production grade stuff, and it's often hard to guess which the author thinks they have.
This is a really important hint. Put a note in that describes what people can expect from you and what not. Maybe there even should be some "standard" for this info, and a place to put it (either in the repo, or in the description), so you could easily find it.
Also, don't forget to update those notes if things change.
Yeah, I really think this is all that's needed.
For instance, it's enormously helpful, in the aggregate, that people have repos that are simply "example of an application that uses Foo with a Bar adapter."
I think this is a good idea.
I will add as a side note, if you can't maintain something anymore, put a big heading on the README.md saying so. If it's popular, point people to a maintained fork.
(Nothing I write is extremely popular but I'm going to go through and "deprecate" a few things of mine tonight)
Github could use the 1-alpha, 5-production system.
At least you'd get a hint at the intention behind the release.
> I do disapprove of this implication. I don't want people to refrain from putting things out there, just because they don't want to feel obligated to support them.
I agree, anything I put out comes with one expectation on my part, I may be contacted regarding it. I do not feel any obligation to support it, I have no relationship with someone randomly contacting me over something.
Though, I put anything I want to be kept private is on bitbucket.
If it's on, let's call it my shithub, there's no social contract.
Have a just witnessed the moment of inception for a fantastic new word?
"Team, we've got to stop all this shithubbing and really start properly testing and documenting our code."
Aside: given that my github name is chickenprop, the obvious name for my shithub would be chickenshit. Sadly, it was registered a couple of weeks ago.
If you're reading this, chickenshit, I hope you make good use of that name.
chickenshittier, chickenshits, chickenshitz, chickenop ? granted, chickenshit is pretty good github name
I think one way to signal that something isn't likely to be maintained, is in the licensing choice. Public Domain isn't a very good licence because of it's questionalble legal status, but in my mind, somehow, CC0 is more of a "do whatever you want, just don't blame me" than eg: a simple BSD/MIT license.
But I think perhaps the core isn't just the license, but also the readme, and guidelines on naming/"trademark": eg: when it comes to markdown, the issue (as mentioned in a sibling comment) was more one of "I don't think what you want do do deserves to be called 'markdown' -- that named was coined for my vision of 'rich plain text'".
I'm generally in favour of strong copyleft licences, because of the need to maintain user (as opposed to, in addition to developer) freedom. But when it comes to stuff that's basically just some ideas that maybe someone else might want to run with -- I think it's important to give them away as unrestricted as possible. Technically trivial snippets of code aren't under copyright -- but with how hostile the "intellectual property" climate is -- I think it's important to be clear when sharing something unfinished that if someone else builds on it, one will not retain any ownership of/claim on the result (beyond what copyright law forces one to keep, hence CC0 etc).
Anything that I think "may" be useful to someone I put up on github. Sometimes to my surprise people use it. I remember putting something up (not even one star/issue or anything ever), then 1 year later getting a random email saying "this is great, thanks." Yeah, no problem, anytime.
I went the opposite direction (kinda) from the author. I realized that people assuming I would fix what I put up didn't matter to me. Sometimes I would make fixes, or check issues, sometimes I wouldn't. Some people got mad, some understood, some were drive by so they never checked back in anyway. Whatever, it's up there, if it really bothers them enough, they can fix it, or use it. It's up to them, not me.
However, I'm still a little like the author. I have a bunch of projects that are "good enough" for my use, but definitely not for someone else (for example, I wrote a password safe[1] cli program because I needed something that would work on FreeBSD. It only handles the features I use and may croak on a file that uses all field types). I keep these off my github.
I find it somewhat mindbending that he advises working on a MVP for 10 projects simultaneously when it's all I can do to work on 1 plus, you know, my real job that pays the bills.
More power to anyone who has that sort of energy!
Maybe it's less about having lots of energy, and more about expending it lazily and efficiently.
For many ideas, an MVP can be a five-line CGI script in bash. Or even a static HTML page. Minimal means minimal.
The MVP is the most trivial thing you can do that will still give you useful information and guide future development. The purpose is exactly to be able to try things without investing significant energy.
What you're describing, to me, sounds like a mockup or prototype. I think of an MVP as something that could be put in the hands of an end-user.
I think you're not supposed to take away the absolute numbers, but only the ratios: so 10 MVPs really means only make MVPs for 1/10 of all your ideas. So one MVP at a time follows the guidelines if you have around 10 ideas!
I agree that any OSS developer should recognize their toy projects will likely not go anywhere and keep a few projects in mind to work on. Keeps things in perspective, keeps one interested, and so on like author said. Doing 10 projects in parallel makes less sense to me. One can accomplish the same thing sequentially while focusing on only a few projects. Just bounce back and forth.
If I went with a rule, I think Google's 80/15/5 rule is worth further exploration. Many of the best projects start with a clear need to solve a problem. Picking one of them and making it happen should be 80% as others will appreciate the problem being solved. Especially true if author understands that domain. A significant step out of the domain or re-application of an effective concept to new domain might be a 15%. A 5% project might be a wild idea with potential but high risk and/or way outside author's domain expertise. The main energy will go into 1-2 80% projects while the 15% and 5% projects are a mental break from that.
This model seems more productive while still letting a person screw around on side projects that might be fun, good learning experiences, or time-wasters with a limit on the waste.
This resonates with author's famous blog post about reading [1]
In that blog post he recommends reading several books simultaneously and abandoning boring books with no regret.
Simultaneous reading is definitely great.
At any given time, I have 2 books, one fictional and one technical, open (made some progress in reading it, maybe not literally open ;) ). I probably could handle an extra technical one.
If I was reading only one book, some evenings I'd be like 'meh, don't feel like reading it tonight'. But when I'm reading simultaneously, I have no excuse to read a bit every single evening, which evolves into a habit and it is definitely a nice habit to have.
I'm really trying to finish one book (fiction), but I tend to fall asleep before finishing a chapter, :p. Mind you, I read billions of words a day (may be a slight exaggeration), and closing tabs when they're boring is common enough. Can't really do that with code though, I need to understand / write / finish those.
TL;DR as a software developer, I find my primary occupation is reading, and not just code. Secondary is typing. I should get a better keyboard.
I've written probably a hundred open source projects in my short professional career. But only two of them do I actually use every single day: a simple OS X window manager [1], and a hybrid command-line/native-GUI fuzzy string matcher [2] (you'd be surprised how many ways/places this can be used). The rest of them didn't serve well as practice like I'd hoped, they were mostly just a waste of time I could have spent better elsewhere.
So lately I have new criteria for how and when to write open source projects: (1) when I realize that I have need to automate something, (2) and it won't take more than a weekend to get a basic functioning version up and running. Anything else, and I nope on out of there. I've got too little time and too many things to do already, I'm not about to waste it creating more unnecessary software. The world has enough of that already.
EDIT: adding links as requested
[1]: https://github.com/sdegutis/AppGrid (note: I started to rewrite this in Swift locally, because Accessibility API sucks without generics, and the Objective-C version is a bit buggy)
[2]: https://github.com/sdegutis/choose (note: I started to rewrite this in Swift, but the Objective-C version gets the job done just fine)
If you want people to be less surprised, or maybe even help them understand what you're talking about, links to those projects would have been handy. :)
Thanks for the idea.
There's a tangential problem I've been thinking about a lot recently: the long tail of open source projects on GitHub.
There are 20M+ repos on there. Which leads to a serious discoverability + signal/noise problem around 'true' open source projects. As someone who wants to put up an open source project for collaboration (with willingness to maintain), it's hard to get the right eyes on it. Too often, it seems like no one cares. Conversely, as someone who wants to contribute to open source projects, it's a little hard to find small early ones where I feel like I can make a meaningful contribution (yes, the big ones maintained by well known companies are easy to find, but I much rather work on something put up by an individual programmer).
How do you cut through the noise on GitHub to find projects you actually want to work with (and want you too)?
Sounds like a good idea for a better unofficial open source search engine. I would be interested in contributing. It could do intelligent search of Github, Bitbucket etc for projects which might be interesting (programming languages, objectives etc).
You could crawl github and bitbucket, make a public dataset available. Others could slice and dice.
I was thinking of something maybe even simpler - a place for people to post projects they're actually interested in maintaining as open source projects. A subreddit could be the mvp.
Or go the other way, and train a searching algorithm based on a data set of actively maintained open source projects on Github, with things like commit history/contributors/etc as features.
If I would reply to all the emails, pull requests, issues, people send me about my OSS code, it could be impossible for me to write a single line of code every day. Eventually I believe the solution is to take what you get from the community, and to provide replies and feedbacks, by spending a fixed amount of time, and trying to sharpen the sensibility to focus on the most promising interactions, pull requests or whatever. It will sound gross to many that expect a reply that does not arrive, but it's better than to stop doing what you love which is writing OSS.
IMO if you've got enough projects that get that kind of attention, it's time to do as any good manager should do, and delegate. Allow others to sift out pull requests and issues, pre-filter emails about the project, so you can do higher-level things (or just write code because you seem to prefer that over dealing with issues)
I hope one day I write something that's half as popular as your code!
I think your blog posts do a good job of answering lots of questions for a lot of people at once - isn't this a more efficient way than answering emails one-on-one?
This reminds me a lot of the idea strategies that James Altucher promotes and uses. They are mostly related to business ideas rather than OSS, but the concept remains similar.
You can see some of his posts on it here:
http://www.jamesaltucher.com/2014/05/the-ultimate-guide-for-...
http://www.jamesaltucher.com/2012/04/how-to-have-great-ideas...
http://www.jamesaltucher.com/2015/07/the-magic-of-idea-math/
I really like this idea. I don't actually have the problem that people are bashing my door down to have me support old code, but my github account has accumulated a huge amount of cruft. Much of it, while quite beneficial for me for playing with something, is completely useless for others. I tend to use Github as a backup system... I'd really like my Github account to be useful for others and not swimming with half finished ideas. I think it's time to clean house...
I have maybe five ideas for decent projects, and I work on two. Why should I bother starting with a huge list and whittling it down?
Maybe you shouldn't. The post is a description of one person's method and should not be taken as prescriptive.
Because you don't know beforehand what projects will keep your attention and what will make you bored.
Or maybe you know. If so, you are better not following his advice.
Strangely this sounds like it might work. I've been thinking about a lot of different projects, and end up doing absolutely nothing. There's also a lot of small stuff that, if I did an MVP, would actually be close enough to ship and be useful. Though I'm not sure about the projects I'm most interested in; they are fairly big and getting to MVP could be many months (so doing even 3 would take a couple of years).
I'm gonna try writing these ideas down. Thanks for the idea!
I personally couldn't succeed with this approach. It's only suitable for polygamists.
I'm more of a one codebase kind of guy. I know how to treat my codebase right.
Just publish and put some clear indicator right there in the README of the status/purpose/scope of the thing. I have bunch of them marked 'experimental', more rarely something gets all the way to 'minimally useful' or 'used in production'.
Arbitrary example: https://github.com/jonnor/agree
It is not for me to decide whether something will be useful for someone else or not, that is up to them. Just give people enough facts that they can make an informed decision.
I'm doing something similar where I publish all main and side-projects (good and bad) and judge interest from retweets, stars and forks https://github.com/heri
However working on 10 projects simultaneously is not feasible imho. 3 or 4 is more realistic, more maintainable and worthwile in the long-term.
I am this way as well. I eventually go back through my Github and delete the projects I am not willing to continue but I put 90% what I do on Github as MIT. Maybe I should add comments to the readme like use at your own risk or some other warning.
How do you gain any popularity at all? Most of my stuff is little hacks, but they have zero visibility. I'm sure something I wrote is useful to someone, but how do I know?
I find it a bit strange to write down 100 ideas of what I could develop. I think it would be much better to just develop some missing software or make a better version of something existing. But just collecting ideas without a real, deep interest in it sounds a lot like the beginning of abandoned projects.
ain't nobody got time fo dat