1.0 Roadmap #67
Description
I've been thinking for a while about what version 1.0 of bork will look like, and I think we're almost there. This project started off as a joke, a "can I even do this" and I guess if you think about a problem long enough, you figure it out. I'm humbled by the interest people have taken in it, and I'd like to open my plan up for comments by the small community that's developed here.
Finish fleshing out each of the types
I just recently added outdated / update support and tests to npm, and there are more types where these are missing. I'd like to complete these.
Add 'remove' commands to types, and an opposite of the ok assertion
This is something I've been thinking about for a while, and in theory it's not terribly hard. Mostly it's come down to semantics for what the opposite of ok is. So perhaps we alias ok to should or pass and then provide should-not or fail. So for example pass brew asserts the presence of homebrew, fail brew asserts the absence of it.
Improved CLI help
I see this as a two-pronged effort:
- Man pages
- a separate help system for individual types to get more details about their usage
Static Website
I have borksh.com and a SSG tool I like working with already, I just need to figure out the Info Architecture and start putting things together. I see this site as serving two purposes: Marketing and Documentation. Marketing is the what and why, and Documentation is the how. I could use the most input on the marketing side of things. I have a rough plan for the docs that include both guides (to help learn) and reference (to help remind), and some good docs-focused friends to ping ideas off of.
Relicense to GPL, contributor agreement, alternate non-GPL commercial licenses, open book-keeping
This will be the most controversial of the items here, but I've given it a lot of thought. The main thrust is, I see bork as something I would like to grow into a truly OSS alternative to commercial tools, and I feel that the GPL provides the best path to get there. I know many developers are GPL-averse because their employers are GPL-averse, but from talking to friends with successful side-projects, they all wish this is something they had tackled earlier. Many companies are GPL-averse for legal reasons and this is fine – I see an opportunity to do something with turning licensing fees into something that can finance development and pay contributors. I don't have it fully sketched out yet but wanted to put it up for discussion.