Shared publicly  - 
 
yeah it's kinda tough when you have 250+ OSS projects, inevitably some get messed up over time and I merge broken shit haha

—the maintainer of n, a node package manager, in reaction to merging a pull request that caused people to have their bin, lib, share and include directories rm -rfed from /usr/local (https://github.com/visionmedia/n/issues/86)

I see a lot of people, particularly from the node community, sing the praises of throwing open source software at the wall to see what sticks. Their argument is that, hey, I'm providing this for free, so the world is better off because there is now more software in it.

No. This is wrong. The world is worse off. There is a limited amount of oxygen in the room for a given solution. Every time you release a new project, you are taking time and attention away from another project that might serve people's needs better. Especially if you're someone like TJ, whose star power will tend to attract people over other projects that, while perhaps better maintained, do not have a famous developer behind them.

If you decide to publicly release a new tool, do it because you truly believe that your approach is sufficiently better than everything else, because otherwise you're causing fragmentation for no reason. And if you release, don't release more than you can realistically maintain. Remember, real people are using this software. Human beings. And they will come to depend on it.

And if you don't have the time or inclination to maintain a project, don't just blindly merge pull requests. It is far better to let potentially bad PRs pile up than to merge to get it over with; especially because it means that it might be YOU that is now responsible for data loss or security vulnerabilities.

Maybe some people don't care, because fuck it, I'm giving it away for free. But I don't think this strategy is tenable long-term, and I think it's poisonous, and I don't want to be part of a community where it's true.

Of course we are all human and we all make mistakes. But I want people who use open source software to be able to trust that, as the maintainer, I will put every ounce of effort I can into delivering a quality product.

Releasing open source software is a responsibility, but I think it takes maturity to realize that. When it comes to whether to release an open source project, I like to ask myself: What would +Chris Eppstein  do? https://twitter.com/chriseppstein/status/235065367045763072
153
52
Tj Holowaychuk's profile photoMikeal Rogers's profile photoHarrison Ainsworth's profile photoDaniel Heath's profile photo
43 comments
 
This is partly why I've held off on open sourcing a tool I wrote. We've used it internally a couple of times but there's enough cleanup and quality stuff left to do in it that I don't feel comfortable releasing it without giving it the proper amount of attention.
 
I understand better now why we have to wait until PRs get merged into ember-data... even if they look good, you feel responsible if in fact, they are bad... I would indeed be very sad if too-fast-merged PR causes my app to crash...
 
So, I should just just stop open sourcing stuff because I have a popular OSS project and of course, my smaller OSS projects suffer? Not sure I agree with that.

You can only have so many OSS projects to give your full attention to. Maybe 2 or 3 at the very most. I'm not, not going to share my implementations, code, and hacks simply because I wont be able to maintain it indefinitely. There's value in just sharing the code. Plus, a developer should be able to spot stale code easily with, "hey, he hasn't committed to this in 6 months" or "hey, there's only 2 commits ever" or "looks like only 5 commits in the past year and they're all pull requests".

Even paid software dies. It's how software works. When a piece of software is no more actively maintained you find different software to switch it out with when you can. Not sure we should be telling new people that, "once you commit to open source you better give your life to it and you must stay with this open project for eternity".

I agree with the fragmentation piece tho, just not the chain-yourself-to-your-project-until-you-die piece.
 
Funny you say this, because ember is quite the gigantic mess..., doomed to fail IMO, will you still support it when it does? Just because I no longer use a project doesn't mean it was not created with the intention to work better than existing tools, environments change and sometimes people don't use a project as much as they once did. I should have reached out for a maintainer earlier, there's no doubt about that.
 
Releasing it with a disclaimer is fine, e.g. if it's a throwaway project, make that clear in the description and README. I'd rather slap my throwaway project on GitHub, where it will live on, then let it die on my hard drive.

And reality is, if you wait for cleanup, that will rarely happen. (100+ draft blog posts in my WordPress says so.)

If it's adding noise, that's GitHub's problem to improve search and browsing based on the kind of signals Google and Facebook use. There's probably a few snippets people might find useful when they search for certain technologies. And if nothing else, it will prove useful to language researchers as well as satisfying my own goals of being able to look back on past project.
 
I think you are jumping to unnecessary conclusions.

The only conclusion I can get from this incident, is to always, with no exception, check and test any pull request before approving.
 
yeah it's pretty simple, I didn't read things well enough (or test), that's about all there is to it.
 
+Michael Mahemoff I definitely agree with you there. There's nothing wrong with making code available; my critique is about constantly releasing software and doing nothing to discourage users from relying on it if you don't intend to support it fully. If I have something like that, I like to throw it on a gist and let someone else run with it if they find it interesting.
 
I thought it was just going to say "... I'm for it." Lousy nuance.

Thanks for that Eppstein thread, it's a treasure.
 
also this has absolutely nothing to do with the node community at large. I fucked up, notice the "I", this means absolutely nothing in terms of the entire community, I make up only a small portion (%1.24) of modules, people have many to choose from. An "inactive" project does not mean it's unmaintained, more often it's likely that the module just has very few bugs or necessary additions. Chris's comments hold no value, Node users on average create clearly defined modules, there's nothing wrong with that
Max O
+
1
0
1
0
 
hmm apparently 1 bad pull request means npm is full of low quality code. cool perception, monolithic framework guy!
 
In TJ's defense: he didn't bump a version number or tag a new release with the breaking change. This bug was, obviously, a huge mistake, but in OSS libraries like this example, you should probably be relying on tagged releases. If this case reflects a problem with a toolset or ecosystem, it may be a prompt for a UI feature on github to flag projects with a rapid decrease in development / commit velocity.

Re: Node and NPM -- NPM has both `unpublish` and `deprecate` commands. Certainly, developers need to be responsible for their creations. But with the community's focus on semver, along with the power of the NPM toolset, I don't think there's a problem with a runaway OSS train.
 
Most of TJs projects have much better testing than Ember. We just don't hear about major bugs from Ember because a bug in a framework that does little to nothing of significance by definition cannot be "major".

When you write your own package manager yourself that is totally stable and never has any bugs ever, then you have the right to complain. Until then; try submitting patches and actually HELPING to maintain these projects, rather than just expecting TJ to do it all himself. He's not some God, he's just another mortal like the rest of us.

Like him, I try to maintain projects even if I no longer use them personally. I've written bug fixes to projects I hadn't touched in a year. I just happen to be a nice guy about it sometimes, but to expect that from everyone all the time is unreasonable.
 
This is nonsense. If you have used any of TJs work you would know that there is a very high standard that comes with his work. Look no further than Ember if you are looking for projects that don't need to exist. Ember is trying to win some bullshit contest of who-owns-the-framework war (btw - its losing to backbone badly). Gawddamn this post makes my blood boil.
 
One thing horribly goes wrong and everyone's questioning OSS roots. Mistakes happen, and this should not stop anyone releasing code even if it's broken, as long as you let people know it is unreliable.
 
Of course without opensource this website wouldn't exist (or Google for that matter), neither would git
 
I think +Tj Holowaychuk's nonchalant response was not the appropriate way to react to a serious issue.  That being said, +Tom Dale has taken this isolated issue and has blown it out of context and proportion in generalizing this behaviour to a whole community.

The implication that Tj's 'star power' in some way should be held against him in his proliferation of open source code is counter-productive.  This 'star power' was earned through repeat contributions of well-written, well-documented and well-tested code.

I think the relevant lesson is that code--and changes to it--that deals with the OS or the filesystem should be granted a higher level of scrutiny by both users and by package maintainers.
 
It's interesting to me how this has devolved into ad-hominem attacks. Tom may be wrong, but bashing Ember isn't going to prove that.
 
Well if you criticize someone else's code, naturally I think they're going to say what they think of yours, though I couldn't care enough to write an entire post about it haha, I have a lot of opinions on Ember but I haven't vocalized them. You can't take one pull request and make assumptions about the rest of my projects. My nonchalant response was really just because there's nothing else you can say, it's a computer, it sucks that I screwed up and made a poor choice but no one died and things will move on as always
 
TJ, I completely agree about it being a natural response. When people say bad things about Ember, my first thought is to troll them. Unfortunately, that doesn't usually end up being helpful. Maybe Node and your projects have been unfairly given a bad rap (in the same way that I find the criticisms leveled against Ember to be unfair), but for us to go back and forth insulting each other doesn't really do anything to resolve these disagreements. If Tom's wrong, lets hear a well reasoned response about why he's wrong. If Ember sucks, lets hear a well reasoned post or list of concerns to which we can in turn give a well reasoned response. We're all adults here (I think) and hopefully we can actually debate the relative merits of the choices we've made instead of name-calling.
 
I think there are a lot of things wrong with Ember, but it doesn't matter, I'm not using it. Does a small screw up really warrant a large troll-like post? not really
 
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
Legal implications notwithstanding, the disclaimer is there to remind users that they alone are responsible for the software that they run. Regardless of how careful developers are, there's always the possibility of some bug causing catastrophic failure. Trying to shame the developer doesn't solve anything.
 
A simple mistake in the dev version of a utility somehow indicates the Node.js community is "poisonous" and one should question TJ's motivations for releasing software? Classy post.
 
maybe a good habit is installing to disposable VMs first.
 
With good practices: source control, semver, ci, testing, good release process etc.. There is no way TJ's issue with n could affect you. This happens. I work for a big enterprise that use node a lot (and other open source stuff) We understand that we have to review, select, and use with care. Code is always YOUR responsibility once you use it. Even if you pay for it. You think IBM, atlassian, oracle, saleforce, etc .. can  compensate you for the losses your business incurs because of a bug they introduce?! psssh Oh and  configure --prefix /not/a/core/directory! This goes for any install on your local dev env
 
Why not standardize "crappiness level" disclaimers then?

Like: "oh, this is 5 on OSS crappiness scale, which is "may ruin your OS and hard drives", should I really try it outside a VM?"
 
says annoying guy I've never heard of in my life, it was a mistake, get over it
 
people who have this attitude don't understand what the internet is for.  it's for cheaply distributing tones of stupid crap and letting the few nuggets of (er...) diamond-cream float to the top.
 
yup, besides smaller things are almost infinitely better, if you design them even remotely right the first time around you'll likely never really have to touch it again with small exceptions, bigger things are always in flux
 
+Mikeal Rogers really puts this into perspective well, I think.  
I'd like to understand more about why +Tom Dale felt so compelled to write this.  

Is it threatening the use of OSS over proprietary software in some way?  Is he afraid that he will get bitten by a similar issue from someone else's module?

Again, I think +Mikeal Rogers really points out the trend and I think it hits JavaScript developers more than most, as it has traditionally been an "Amateur's language."  However, this is not the first time I have experienced this: I live through Visual Basic 3, 4, 5, 5 32-bit, and 6 also while doing C++.  The same complaints were leveraged then about VB enabling "English majors" to write code that could bring down a company's financial systems.  It never really happened.

I think it's important to recognize:
a) the culture of Node.js and small and composable pieces (love it)
b) the history of JavaScript and its audience
c) the very low barrier to participating in Open Source community (GitHub, BitBucket, etc.)
d) the benefits all of these things bring given some of these tradeoffs

Anyway, I'm not too sure where this goes next, if anywhere.  I still don't understand the motivation to begin with and maybe understanding that would help focus the discussion?
 
+Mikeal Rogers Thanks for your thoughtful response. This was exactly the sort of thing I was looking for. Maybe I don't come off this way to some people, but in fact, my opinions are quite malleable. I post the opinions I have at the moment in the hopes that people smarter than me or with different perspectives will help me hone them. So far the level of discourse in this thread has been embarrassingly low. Thank you very much for raising it.
 
+Tom Dale, I think you make some interesting points, but when you convolute one incident with an entire community of open source developers and assert that their way is "wrong," you come off as a bit condescending. If your intention was to learn something, your original post could have been better phrased. Perhaps if you did that, you would have set a higher standard for  "the level of discourse." I know we're all passionate about our software and methodologies, but I think it's still important to strive to be considerate in how we address others with differing opinions.

As +Mikeal Rogers wrote, these clashing "old" and "new" schools of OSS obviously have different values. I suspect each have something to learn from each other. So please guys, let's keep it civil.
 
TJ's dilemma is difficult. It's hard to transfer a project from one developer to another on github.  There may be 100 forks of n, but there is no easy way for me to look at the original project and find which of those forks may be worth following.  

TJ sold me on the first version, but John Doe has no chance of selling me on his new version because I would have to wade through 100 forks that are mostly garbage to find his new and improved version. The result is that TJ is pressured into accepting patches for something he doesn't want to touch.

It's a hard but important problem.
 
If the original developer has lost interest in a project, they can transfer the repo to another user (it's in the admin panel). or just link to that fork. 
 
These seemingly conflicting views are actually part of a greater system that constantly expand and condense and is cyclical; both are necessary.
 
you can also add people as contributors if they're interested (I've done that now), there's no question that I should have done that earlier. Resume beating the topic with a stick
 
thanks +Tom Dale , you have discovered why i don't have comments on my blog and force people to disagree with me on twitter, in 140 characters or less :)
 
One solves a problem of many choices by being better at choosing, rather than by restricting what you have to choose from to start with.

By saying the author themself should filter gives them an impossible task: because whether something is useful for a community is a question only the community at large can answer. It would be making the choice in the wrong (or sub-optimal) place, because the author lacks the needed information.

Ultimately we should do two things: 1, release everything (without prejudgement), and 2, be better at describing and searching for things. That looks like one of the fundamental strategic bases or structures of globalised software development. http://www.hxa.name/notes/note-hxa7241-20120901T1034Z.html
 
I see two kinds of open source releases;
1) "I found this useful, feel free to copy it" (imo best served by BSD style licences), and 
2) "As a service to my community, I distribute this useful package" (imo best served by GPL style licences)
Add a comment...