Hacker News Reader

Nicely said.

As a long-time developer from the embedded world, I'll add the same sentiment. I've written 25 years of code that's 100% proprietary to my employers and my customers.

I've never touched Github and, at this point in my career, it looks like I never will.

Granted, I have a product portfolio that I can point to instead. The rubber has to meet the road sometime so yeah, in the open-source world that's the only visibility you have so you go with it.

> The rubber has to meet the road sometime so yeah, in the open-source world that's the only visibility you have so you go with it.

This seems like the real takeaway. An experienced programmer should have some evidence that they do good work, whether that's products or OSS commits or something else altogether (e.g. someone in security who can't talk about their work details but does papers and conferences). Good hiring means being able to adapt to where a candidate has spent their effort.

My github is where I keep that, now. In the past, I had some example work I could pull up and show, but for the most part, all of the stuff of my past employers is behind closed doors, so to speak.

...if it exists at all anymore!

In many cases, the examples of my work have evaporated. At one point, I could point to certain websites I had a hand in developing as an employee for past employers - but those sites have since changed, moved on to other software development companies (one of my past employers folded and those clients went to other agencies for web dev work). I can still list I worked on such work, but I have no code or other proof.

So my github (and interview results/conversations/etc) are where its at - and ultimately, that's where its always been (I've been doing software development work since the early 90s, when I was coding on VT100 terminals over a serial link).

Yup, perfect example.

Ironically game development is one if the areas where tech & algo is discussed widely and openly(which is what GDC used to be before it became a bit more commercialized). Most studios are happy to share their latest pathfinding/ai/rendering techniques which is almost always held close to the chest in other industries.

Even more perfect because 2048 was the open-source clone, and we're not even mentioning Threes, the game on which it was based.

Yeah, I've always been annoyed at the lack of recognition Threes tends to get.

Threes is great, and I bought it when I realized 2048 was based on it. And the makers of Threes were right! I have never gone back to 2048, but I still sometimes play Threes.

That's an interesting point - game companies are particularly defensive of their code, but shockingly willing to share the latest shader techniques and other insights most fields treat as secrets.

I think that's just because that for the most part, their competitive edge is the creative work as a whole, not some particular technique.

Their techniques doesn't save corporations that could purchase their software time and money, for example, it just helps make one aspect of the game look or feel cool.

That's a part of it for sure. I think another piece is that everyone I knew in the industry was there because they loved games and money wasnt a primary(but was an important) concern. For instance I knew every title locally under development long before(6+ mo) it was even leaked because there's a sense of shared community in that industry.

> their competitive edge is the creative work as a whole, not some particular technique.

Never worked in the industry (and don't have a desire - though one time I did), but I'd have to say that's spot on. You can have all the fancy shader tech and other 3d gismo engine whatever at hand, but without the story/plot and creative content, anything you made using it wouldn't amount to much.

...and that content is very difficult to make! Even a simple 2D game can have a load of content and design behind it that can't be easily replicated for a new title by a single person. Though this kinda argues against why more companies don't release their engines and tech as open source - especially once the tech has "aged out" (fortunately, a few companies have - like Id Software, among a couple others).

Even with these releases, though, you don't see a slew of others coming out with games and such based on the code.

Game dev here. People don't share engines because there is no reason to. Unless I'm trying to license my engine out like Crytek or Epic there is no reason for me to open source my entire engine. You can talks all the time about the interesting parts of engines, tools, and techniques but there is no reason for a company to just be like "here is our engine bye"

25 years ago people would have said the same thing about OS kernels, and yet here we are. Some of the underlying problems I see are that the game industry is still young and hasn't really standardized everything yet. Because of that, there is still ruthless competition between the hardware and GFX card vendors. Vulkan is a step in the right direction, but it will obviously take time for it to become adopted.

A lot of it is also driven by the popularity of consoles and mobile devices which are still largely locked-down walled gardens. They intentionally make it difficult to share code between platforms too. But, soon enough game developers will get sick of writing the same code over and over again, just as OS developers did in the 90s. Once this happens you'll start to see a lot more ad-hoc code sharing which will pave the way for more engines being made free software.

That's a pretty naive view of things, it's not the lack of GPU standardization that drives engines, it's the fact that fundamental bits of gameplay drive very diverse engine requirements.

For instance UE3 makes a horrible engine for open-world games since it's built on loading levels whole-sale and doing very little streaming aside from textures. If you need a game that requires 60FPS(racing, fighting/etc) something that is GC based won't cut it.

I've worked in in-house and external engines(UE3, Unity) and you always have to re-write large portions to make them work for your gameplay. There are fundamental tradeoffs that make it hard to do otherwise. At every project there comes a point where you no longer take unlevels from mainline, fork the code and make deliberate breaking changes to ship the game vision that was set out by the team.

Games typically come with a lot of creative assets such as artwork, music, etc. that are copyrightable in their own right, but out of scope for open source licenses. Those assets could be released under a permissive license too (like Creative Commons), but a potential route for an "official", albeit open source game release would be to release the code freely, but not the assets. That could lead to clones with subpar assets, or -- just maybe -- someone/studio/whatever will create superior assets, improve on the game engine (as they're free to do so) and now you have a better game.

Rinse. Repeat...

The great thing about viral licenses like the GPL is that they effectively openly track the provenance of the original idea/implementation. If someone comes up with a really neat game (in terms of its concept and, ultimately, source code) and that gets built upon openly, the original copyright holder will still be credited. Plus, if the source freely exists, I think most would be more inclined to fork than to reimplement a clone from scratch (modulo platform support, I suppose).

Remind me how Counter-Strike got started again...

Between mods and Ludum Dare there is plenty of room to make a name for oneself in the open.

As someone who did mods for years I think it can vary widely. A mod can become as consuming as a job, yet without the benefits. While a few have hit it big there are plenty more whose creators have nothing tangible for their efforts.

> for example, 2048 and Flappy Bird both had open source versions, possibly unofficial

I know you're using them just as an example in your comment and this might lure people away from your points, but the "original" 2048 (the one we all fell in love with) really is open source. In fact, it got to the front of HN with almost 3k votes, and the author left multiple comments in that thread.

So yeah, my point is, the "original" 2048 is not only open source, but HN definitely had some sort of an impact on it becoming a thing.

https://news.ycombinator.com/item?id=7373566

Actually I knew that, the 'possibly unofficial' was more in reference to the Flappy Bird github repos I've encountered. I've checked the code for 2048 a few times to see how HTML5 games can be made (I used to make Flash games).

The original 2048 was not the 2048 we all know and love but the non-open-source iOS game "Threes" of which 2048 was a clone. Here is their story http://asherv.com/threes/threemails/

> Good luck getting the game industry to make their AAA games open source, especially before release, when hundreds of people are chomping at the bit to have a dirt easy time of cloning whatever game out there and tossing it on the app stores to make a few bucks off their broken, half-stolen mess of a game. It's a rampant problem right now (for example, 2048 and Flappy Bird both had open source versions, possibly unofficial... look how many clones of those games hit the app stores).

Your examples of AAA games with open-source versions are Flappy Bird and 2048? We have different ideas of what makes a AAA game...

No, I can't think of any AAA games that have intentionally released their code open source (unless it's years and years after the game has been released, like Quake, for example). They usually only add mod support. Probably the closest thing to a AAA game where the source code was fully available was Minecraft, but that's because it was originally written in Java and thus easily reverse-engineered.

2048 and Flappy Bird were to demonstrate the cloning problem that App stores have been dealing with, in part because of how simple those games were to recreate, but also in part because it was made even simpler because the code was easily available.

For an example of something closer to the problem that AAA would face if they made their code open, look to the shitshow that Steam Greenlight faced that Valve had to put a stop to. People were downloading some Unity assets and slapping together total broken crap as fast as they could and selling them as full games. That's the type of thing you could expect if AAA was more open with its code.

It's 2017 - we're all living in the Open Source bubble: http://www.networkworld.com/article/3120774/open-source-tool...

"The future is already here, it's just not evenly distributed yet." - William Gibson

Hi, author of the article :)

I don't deny that open source is now more prevalent than it was in the past, I just don't think it's on the verge of taking over the world, where every sector will be open source, especially in the ridiculously short timeline of 12-24 months you stated in the article. There's too much value for certain industries, sectors, or companies to keep some, or even most things close to the chest, and there are plenty of companies that haven't been convinced that opening up their codebase would be worth the extra time and effort it would take to do so.

You didn't even address my example of the game industry, so I have no choice but to assume you either agree with me for that industry or just don't have any way to disprove it.

Yes, Microsoft, once known as the chief closed-source proponent, is now embracing open source more, but that's a single company with completely different management than it had ten years ago and in an environment where they're no longer the king of the development world. And in particular for developers, being more open is usually a good thing because it gives us more freedom when developing. But that's only one sector of the programming world.

I have worked for at least a dozen companies over the years, and while I've incorporated at least little pieces of open source software or libraries in most of those jobs, the resulting codebases for those companies was never opened up, nor was there ever any talk about possibly opening it up. We were generally always too busy working on the next iteration to worry about opening our software up or dealing with that. Additionally, at least once I recall us rewriting our application to remove an open source portal software (uPortal) it relied heavily upon because uPortal was just a convoluted, restrictive mess to try to do any real customization with it.

And quoting William Gibson, is cute, yet proves nothing. He's a talented writer who tells good, believable stories about future technology, but he's hardly a prophet.