This question has been asked a lot, so thankfully I've got an easy answer: You don't actually want to build on top of our UI toolkit. We make breaking changes all the time, there's very little documentation and no release cycle at all. This isn't a problem for us as we have in-house knowledge and can fix any breakages trivially, but you don't want every open source project to have to maintain it's own fork of a UI toolkit.

I completely support this. I write a ton of open-source software, and have many published packages.

Each one that I publish is a Responsibility. Like a parent that has children, the package is no longer “completely mine.” All changes and fixes are made, keeping in mind that someone may be dependent upon my work.

I’ve been writing SDKs -literally- my entire career (I can link to my very first engineering project, in 1987, where I designed a hardware system, and a companion SDK).

A perfectly legitimate reason for keeping code private, is that I am not willing to support it for any use, other than my own personal use.

There is no obligation to support the code at all though. You can release it once, say it’s unsupported, and let the community pick up maintenance / forks if there’s enough interest. Otherwise, no harm done.

In practice it doesn't work this way. Saying it is "unsupported" does not mean people will respect that boundary, nor will it prevent people from contacting you expecting your time and attention, which is what actually happens. There is significant overhead to open sourcing software.

This.

Even for code I didn't publish (like corporate SDK internals), I have been contacted (which took some work, because my employer did not like customers interacting with Engineering), and told (not "asked" -told) to make changes to our corporate, closed-source SDK to suit some rando's tinkering around (also, for extra credit, said rando hadn't even purchased one of our cameras).

Even open-sourcing has its caveats.

Anyone that has spent any time at all, on most tech forums, have seen the "Open Source Holy Wars" being fought.

I tend to use the MIT license. I won't go into the reasons why. I write OSS, and I support it. I choose to do so under MIT.

In the past, I have been contacted (I make it easy to get in touch with me), and told that I was a "corporate shill" for not using GPL.

That's always a great way to start the day.

Also, our corporation had to fend off a few legal threats, because some of our software looked vaguely like some GPL stuff (I guarantee it wasn't -they were anal about the GPL), so zealots would sometimes throw sueballs (or vague threats, thereof) at us.

At least the patent trolls would do a little bit of homework before attacking us. These folks wouldn't even bother wondering if they might be mistaken before unleashing the hounds.

Can't you just ignore them?

People won’t respect the boundary if you host the code on github, because it’s just too easy to open issues or pull requests.

However, what about just releasing a zip file with the sources and linking it on your downloads page?

Someone should make sourceavailable.com - A service that automatically pulls my private repos from GitHub and makes it available as open source to other programmers. A read only version of GitHub, without the isssue/PR overhead.

Code should be easy to read/download on https://sourceavailable.com/username/repo

Someone bought the domain after I wrote this comment. Hope they’re working on this idea :)

Some people did close the issues and store them in a directory as plaintext on the repo. Want to report a bug ? make a PR. the extra little friction was added so that you need to spend a little time (and having spent that little time you might as well research a bit your bug or read the doc). Bonus point, your project is now completely portable.

> and let the community pick up maintenance / forks if there’s enough interest.

This almost never happen, even when the interest is very high... I love open source and free software, but we should face that this point is more a fantasy than a real thing.

I would say, it depends on the codebase and documentation. Taking up a abandoned mess of undocumented spaghetti code? No thank you. And most "open sourced" repositories are like this.

But the ones that have at least rudimentary documenation, something a new maintainer has something to work with - those are the few ones, that might be picked up by some community. Rare, yes - because there is not much fun in writing documentation on your personal pet project in your free time. But it might be still worth it.

You could extent your UI toolkit and profit from it. make it open source and make it free for open source projects and with fee for commercial projects. It's very beautiful and sleek UI and the market of UI are lacking in this area. a lot of people demand this UI toolkit and asking you to release it is a prove that it will be a successful product.