Hacker News new | ask | show | jobs
by michaelschade 2979 days ago
(I'm the author.)

We regularly discuss this :) I'm not sure yet how valuable open sourcing it will be in the long run. Part of what makes Home work well for us is how tied it is to how we actually work day-to-day -- that regularly changes as we grow and learn. As an open source project, we'd feel a commitment to keep it working for the existing user base, which might perversely hold back progress on Home and be a net negative for the community as Stripe itself tries new ways to operate.

For now, we intend to continue sharing the lessons we learn from Home and similar tools so that others can benefit from that, and to keep open sourcing it in the back of our head as we design the underlying APIs and infrastructure so we have optionality if it makes sense down the line.

8 comments

Actually a good example is Blueprint CSS framework from palantir (https://github.com/palantir/blueprint). It's fully tailored around their design philosophy and they are not beholden to anyone else.

However you have to remember that your scale, we will follow you (and fix your bugs) rather than demand you serve us.

Who knows we both might learn off each other !

Look at, say, Circle CI open sourcing their front end. Just because you release the source doesn’t mean you have to make any commitments around it. You get to decide what commitments you make.
Who’s using their open-source frontend?
I doubt anyone - it's not useful for anything apart from creating an identical clone of Circle CI.

They didn't open source it for other people to use, they open sources it for other people to learn.

This seems like a weak argument for not open sourcing. Just because it is open source doesn't mean you need to accept any community suggestions, and it doesn't mean you can't make radical changes because you want to. Even by doing this, you're still giving back because people can learn from it -- kind of like how a patent gives back.

You are the project owner after all, and if someone doesn't like the way you are going they can just fork it and continue on their own.

I think you're making a weak argument for how easy it is to "open source" something. Sure, publicly releasing the source code might be easy, but that's not what 'open sourcing' means to most people.

You're right tho that they could do everything you describe, i.e. publish the source code and not actually participate in any 'open source' community projects that might spring up around the code. I'm guessing that's not really that attractive to Stripe, or lots of other people. It's work just to remember to push commits to the public repo, even if you're otherwise ignoring all public communications about the project. (And ignoring all the public communications, e.g. blog posts complaining about the company not collaborating with the community, is work too.)

> Sure, publicly releasing the source code might be easy, but that's not what 'open sourcing' means to most people.

Still, if they are upfront about it, I don't see how it's an issue. If one of the first lines of the readme is something along the lines of "Because we believe in open source, we are making the source code publicly available for this product. We hope you may learn from it as much as we have, and perhaps adapt and use it in your own organization. However, there are currently no resources allocated towards making this a plug 'n play product for others (we are not your software development team) and therefore we will not accept pull requests or issues."

Perhaps that sounds a bit harsh in its current form, but this is just a draft of what it could say. I think the vast majority of people would understand that it is indeed unreasonable to expect them to spend money on your whims and wishes for no good reason.

I don't think most maintainers of open source projects would agree with your optimistic expectations about the reasonableness of the vast majority of people.
Hey @michaelschade, how do you guys sync the system with new hires? Does home hook up to some sort of HR system in the backend like Zenefits or ADP to sync?
Good question! HR system on the backend is the source of truth for people, their teams, and the org structure; we normalize that into an API, which Home functionality and other internal tools integrate against.
Awesome! Thanks for the response. So Im assuming Stripe doesn't use any outside vendor for HR people management and that it's a home grown product?
It it still built with Ruby?

I would much rather it is provided as it is. I mean No one should ever think of Open Sourcing it as a responsibility.

Any timeline on when it could be a product other companies can use? Perhaps as an early alpha/beta?
What tech stack do you use for your project?
Primarily Ruby, React, Redux, and ElasticSearch (backing our search API)
Is Home going to be launched as a product?