Now this is how you pitch your product to an open source company | Hacker News Reader

Now this is how you pitch your product to an open source company

blog.reddit.com

146 pointsarthurgibson19 comments

Congrats to the embed.ly team for doing it right and making our job easier.

You're welcome. A lot of credit has to go to Chris and the Reddit guys. They were awesome. One phone call, some code, a few emails and it was done.

(I'm one of the reddit guys) ;)

Just curious, but what's the business model behind embed.ly? How does one generate revenue from such a service?

I'd like to know that too.

The only product I see here is an open standard which would be forked the moment they try to slap ads on it.

Love the TLDR summary at the bottom. That should become more of a trend.

I never got why its standard practice to put it after the "too long" part? Shouldn't it be before?

I guess semantically using "didn't" is past tense, implying some type of initial attempt to read it and then because it's too long, you didn't. But nevertheless it would more helpful at the top?

Since you asked, my guess is psychology. If it was at the top, then most people wouldn't bother reading the comment, as they already know the conclusion.

TLDR is useful for and needed by those who are skimming.

It also makes for a nice summary if you read the article.

As a guy who runs a reddit install, I am pleased to hear that we'll be getting updates soon. : )

Is github going to be kept in sync with reddit's copy now? Is that the idea there?

We are trying to be a lot better about keeping everything in sync.

Our goal right now is to publish weekly, but we'll see how that actually works out.

The best way to keep in sync is to remove the need: just publish everything live and unfettered to a public repository.

We used to do it that way, but we stopped because it was breaking people's installs. Sometimes we have to push half-baked code, and if you sync at that point, bad things may happen.

Also, we stopped doing it because it meant revealing features before we were ready to reveal them, like sponsored links. That is when we split the public and live repos. Before that, the public repo was the live repo.

Hi, thanks for responding. Obviously, I'm not involved in reddit development, since I didn't know you used to publish live. But still, I think it's ok to have half-baked code out there -- you just need to mark releases occasionally. Those can be as slow or frequent as you like, but it's still important for people to see what's going on in the interim. And in turn, those people can help you get it fully baked.

As for controlled feature revelation, I think that's counter to the spirit of open source community -- the community is not really on equal footing with the company. It like you're saying "aren't we nice to share our code with you" rather than "let's all work on this together".

Well that's my two cents. I understand that not every company feels they can work that way, but I think the really successful projects have figured this out.

> As for controlled feature revelation, I think that's counter to the spirit of open source community -- the community is not really on equal footing with the company. It like you're saying "aren't we nice to share our code with you" rather than "let's all work on this together".

We very much embrace open source -- we use only open source software and we contribute back as much as we can.

However, we are still a for profit company, and occasionally have to keep things secret (especially new features, for competitive reasons).

So yeah, unfortunately the community really isn't on the same footing as us. The idea is that the code is modular enough that if someone wants to work on a new feature, they should be able to do so without having to worry about what we are doing, and for the most part that is the case.

Well, part of the git workflow is branches. If you embraced these, you could push your full-baked code, your bug-fixes, and everything onto master, and just keep sponsored links code in a branch. You can create a "live" branch that reddit.com runs and merge in master + relevant other branches as necessary. It just seems like things would be a lot easier on both of our ends if at least the bulk of the code tracked the production reddit.com fairly closely.

Also, as CUViper suggested, I think that tagging releases and providing tarballs of these is a pretty good idea. Right now, everyone is just like, "I have commit z1z1z1z1, what do you have?", which most people can't easily memorize like a version number.

Tagging "versions" can also help with dependency changes -- for instance, the new codebase uses Cassandra instead of memcached (as I understand it); if you have the last release (currently HEAD on master) tagged as 1.2 or whatever, you can say 1.2 needs these things: x, x, x, x and our new release 1.3 needs these things: x, y, y, x. This really helps people, especially people who use "server" distributions, because many of those have only certain packages and versions for quite a while (see RHEL or Debian), like, 3-6yrs in most cases, some people go longer (some shorter, but not that many imo). master HEAD of course would be the latest and greatest without any necessary warnings, because things are expected to break on a development version. Versioning is pretty important imo.

> Well, part of the git workflow is branches.

Internally we use a lot of branches and tagging and versioning, etc. The problem is if we published everything live, it would add a lot of overhead for us.

While we do eventually publish everything, we are still a for profit company, and occasionally have to keep things secret for business reasons (like new features). Keeping track of what code is for a new features vs a fix to an old one would add a lot of overhead that we just have the time for.

In the name of reduced overhead, we only publish to the public repository once we have released a feature and it is fully baked.

Love the idea. I did find a down page btw.

http://api.embed.ly/about

nice

Reply on news.ycombinator.com