Open sourcing a Contracted project: I toggled the “public” switch, now what? | Hacker News Reader

Open sourcing a Contracted project: I toggled the “public” switch, now what?

medium.com

55 pointsalonisser31 comments

I just pushed an effort at Linode to open source our new manager website: https://github.com/Linode/manager

I think it will avoid these pitfalls. It is a learning resource because I hope that someone will read it instead of spending the weeks we had to spend figuring out how to set up the ideal frontend web project in 2016. I also hope that it'll get some exposure among those millions of open source JavaScript projects by simply inheriting our customerbase.

Unfortunately, though, I don't realistically see many external contributions coming into the manager. It hits all of the points that make it easy to contribute (it's not my first open source project by a wide margin), but I would be surprised to see many contributions despite that.

> It hits all of the points that make it easy to contribute

Where's the documentation?

> Reporting Bugs

> Don't.

Hmm...

Yeah, fair. It's still early in development so those resources haven't been made available.

Fair enough, I just wanted to point out documentation is pretty much the first and most important thing you need to do if you want someone to contribute to an open repository, so I don't think you can say it "hits all the points" without having any docs available.

Well, I do see significant amounts of contributors working on several of my personal open source projects, and I only generally make end user docs available. A well organized codebase doesn't always need much explanation.

Open-sourcing side projects is fun only if you care about those or until they become more popular. One of the tiny libraries I developed some time ago has 1000+ stars as of today, and though I have no interest in developing it any further, I keep receiving bug reports, questions or pull requests. The questions tend to be on the silly side, most pull requests would break the code for others. Most of the time it's a pain really, yet, I have to keep it out there and make it available on Cocoapods too, mostly because the last thing I want is to break other dev's projects.

I fear that opening sourcing my personal projects would work against me. The code that i develop in my spare time is done for my own benefit, and just for fun - no documentations, no unit tests, and there are hacks there which i'm proud of.

I fear a future employer would look at that code and think that is how I write code in professional environment.

You could create a repository under a nickname not directly tied to your "real" name. Having multiple virtual identifies is one of the best features of the 'net.

This article seems relevant for my situation. A few days ago I released project management software called Wheatbin: http://wheatbin.com. It's my first contribution to Open Source.

The github repo is here: https://github.com/wheatbin/wheatbin

The software works great for my needs, but it would be nice to see Wheatbin evolve through community involvement. I wasn't sure if that happened organically or if there were things I could do to get that started.

There is no such thing as "if you build it, they will come". I mean, the movie "Field of Dreams" was about a literal miracle, after all. Open source software takes just as much marketing and "sales" to convince people to use--say nothing about contribute to it--as proprietary software.

> There is no such thing as "if you build it, they will come".

Who is marketing Redis, Postgresql, UBlock, VLC? I understand the opposite doesn't apply to everything but neither does the blanket negation.

Attention for uBlock AFAICT started with a widely shared blog post comparing its performance to other Adblockers. From there on it's probably word of mouth, but writing that blog post and getting attention to it was "marketing", even if maybe not intended that way. And it was good marketing, since tech loves "This thing is proven to be sooo much faster than the old thing people don't love 100%" stories ;)

Postgres is very heavily marketed by EnterpriseDB.

Your post explicitly states:

> Open source software takes just as much marketing and "sales" to convince people to use--say nothing about contribute to it--as proprietary software.

The comments in response to my post have been about the author's of said software publishing blogs - are you really equating 1 author publishing a blog with the 'marketing and sales' used to sell proprietary software (as in dedicated sales team, dedicated marketing teams, SEO, dedicated social media/pr employees)?

> Postgres is very heavily marketed by EnterpriseDB.

Saying that Postgres is 'very heavily marketed' when drawing a comparison to the marketing proprietary software receives isn't just misleading, it's false.

Their evangelists doing talks at developers's conferences.

VLC was (is?) written about extensively by blogs like Lifehacker. It's one of the most recommended programs on forums. I'm surr it started by the creators letting people know about it.

Please take a look at the new Core Infrastructure Initiative Best Practices Badge. https://bestpractices.coreinfrastructure.org/

It helps list what it takes to have a project that is usable by others and to which they can easily contribute.

Do you think it might have been responsible to disclose that you are a "Senior Advisor" to this coreinfrastructure initiative thing?

I guess I thought I did, since it's right there if you click on my username. Also, the badging project is completely free and open source (we're also eager for contributions about improving the criteria), so it's not like I'm aiming to rack up my affiliate commissions. But apologies if it came off as irresponsible.

Thanks for writing this.

It lists many reasons why I don't open source my side projects.

Open sourcing is meanigless without considerable additional work in form of quality assurance, documentation, project management, marketing.

As a developer you should weight whether it is worth the cost for the return of exactly what? Getting your stuff out there? Developer street credits? Maybe a consulting gig down the road?

Or is your time better spent doing other things?

I don't see how open sourcing is meaningless if you don't do the things you listed. It may be meaningless to you, but you can never tell if someone else will be able to benefit from your work.

In theory yes. In practice no, your project will just be burried amongst the million other github projects.

But it's more useful to the ecosystem as an unmaintained code dump than being kept closed. If there's interest, someone will pick it up partially or fork it. In the worst unmaintained, unused case, it's still potentially valuable for code archiving/history purposes.

Not in my experience. I've pulled some very useful things out of tiny projects on GitHub, most recently a friend and I fixed several performance issues in a great voip.ms SMS client for android.

Tiny, obscure project but it was just what we needed, after a few fixes for our use cases.

I've found quite a few interesting and useful things in inactive zero-star github repos. As long as title and description are useful for search and it is not something that is totally done to death your project might be surprisingly easy to find.

Sure, but it may be the only one that's doing exactly X with Y in Z language, especially when you step outside of Java, .NET, and the other "enterprise" languages or working with hardware devices.

Depends on the project. I've seen the argument from game developers (e.g. dwarf fortress) that open sourcing the game takes a lot of effort. I wholeheartedly disagree. You flip the switch, make sure there's an appropriate license, and the community can do whatever they like with it, and if it's well-known enough, they will. Native source ports for example. Which just happen to be the biggest reason I want the source to games.

I don't know how much clean-up id did on doom's source before releasing it, but my understanding is that they didn't do that much. And I wouldn't be playing Doom today if it weren't for that source dump.

I'm not playing dwarf fortress. I kinda would like to, though.

I have to disagree as well. Years ago I open-sourced a little utility on GitHub and stuck the GPL on it. I had to stop working on it and soon forgot all about it. I checked on it recently and discovered that it was forked by PhoneGap and is now a critical dependency of their product. I don't recall doing anything to promote it.

Thank you for Fruitsrap. We use it every day, as do dozens of other teams you probably have never heard of :)

Open sourcing can be useful to others without taking any non-trivial time on your part.

For example, in the early '90s I wrote a tool to pull a small newsfeed from an NNTP server. I called this tool "suck". It was written entirely for myself.

When I finished adding new features that I had not realized initially that I needed, and finished fixing all the bugs that I new about, and had used it for a while without encountering any new problems or discovering any new features I wanted, I made the documentation presentable, made a tar ball of the source and documentation, put it on my public FTP space at the University of Washington, and made a single post to usenet announcing its availability and location, stating that it was public domain, and stating that it did everything I wanted and I'm not going to be doing any further work on it and would not be doing bug fixes or enhancements unless they were fixes or enhancements I needed.

So aside from the small time spent cleaning up the documentation and putting it up on the FTP server and writing that one announcement post, open sourcing it took no time of mine.

A year later I had some enhancements I wanted. I made them, and then like last time I put it all in a tar ball and put it up for FTP. I then went to usenet to post an announcement that suck2 was now available, on the same terms as suck, and to my surprise I found that someone else had just announced suck2.

They had found suck, and it did much of what they were looking for, and had used it as a starting point to make the tool that they wanted. They were actively maintaining and developing their suck. I kept using my suck2, since it did exactly what I wanted, but from then on if I had occasion to recommend pull feed software I recommended the other suck2.

Their suck made it into several Linux distributions. By then they had changed enough that I doubt there was any code of mine left, but it was still cool to see something that had started from something of mine there.

As long as your side projects aren't in a state that could harm someone who tried them, why not release them? Just make it clear and prominent what level of post-release interest you have (and "none at all, including ignoring all communications about this project" is fine).

I don't quite agree, there doesn't have to be a compelling reason to write and store your code in the open. I put all my 'weekend stuff' under MIT license on github by default, unless there's a really good reason to keep it closed. I really don't care about the cultural or political aspect of Open Source, and in the end I don't care if the code is used by others or not, even if it feels good if the code is useful to others. I accept, reject or ignore pull requests without feeling good or bad. The chances that any of my code becomes successful and a burden are very slim.

The thing is simply: it is easier, cheaper and less risky to make the code open than keeping it closed on my home machine or in paid private repositories.

Reply on news.ycombinator.com