I’ve been doing the “No Nonsense” amateur radio license study guides for almost 20 years now. Yikes! That’s a long time. It’s been a lot of work, but satisfying work. It’s a good feeling to know that I’ve helped literally thousands of hams either get their first licenses or upgrade to General or Extra.
I’ve been thinking about this today because, in exactly one year from now, we’ll have a new Technician Class question pool. And that means that I’ll have to produce a new study guide.
So, as I sit here today, I’m thinking how can I make the study guides better, while at the same time make them less work? One thing that occurred to me is that I could make them open source and then freely distribute them. I’d make less money on them, but it might be an interesting experiment.
If you have some experience with open source projects, and are interested in participating, I’d love to hear from you.
I worked on an open source document – a glossary of computing terms – which eventually got turned into a proper glossy report. We were reasonably effective in getting a range of people contributing and producing something fairly quickly to meet a deadline.
The first pass was a bunch of people using a shared structured editor (Google Sheets) to put together a “one line per item” version of the document. This was helpful because you could swarm on the task and have a lot of input without people stepping on each other too much.
When the first pass was done enough, I converted the CSV file into Markdown, and unwound the individual records into paragraphs, so that it was easier to format into something pretty. There were still some substantial text changes at this point, but the document was mostly “done”, so we could handle and discuss individual changes with pull requests in Github.
Finally the Markdown file went through Pandoc and ended up in a pretty PDF format, which exposed all of the typos and thinkos that were invisible when the text was plainer.
Since there are chapters you could easily work on this one chapter at a time, and not have to worry about edits on an overly-long document getting too horrible; or you could break it up one question at a time, and have your Makefile assemble the final copy or even if you are careful with the formatting generate something for some other system like a flash card setup.
All this long-windedness is to say that this is not an impossible project to imagine as open source and cooperatively written, but my experience with it was that creating the collaboration environment took some work, and the tools I had were just awkward enough to sometimes get in the way of good writing.
Have you considered Crowdfunding? Like Kickstarter and/or Indigogo?
I’m not a radio amateur and never used your guides, because I have considered it for a long time, but just have too much on my plate, but I’m still subscribed to your blog… And I thought I’d mention that in case it might be of help.
No, I’ve really never considered either for the study guides. I do pretty well on sales, so funding is not really a concern.
I’ve made some contributions to the Solr search engine documentation. That is maintained in Github, in the AsciiDoc format (https://asciidoc.org). AsciiDoc is pretty easy to write, friendly for source code control, and powerful enough for technical documentation. I love MarkDown, but as soon as you need chapters or footnotes, AsciiDoc is a better choice.
This works with people submitting changes, then a smaller number of “committers” (editors) approving those changes.
This is a formatted section of that document:
https://solr.apache.org/guide/8_9/circuit-breakers.html
This is the changed version that I’ve submitted:
https://github.com/wrunderwood/solr/blob/4b93ec27ac7e7b26f3745f90c41268b3fe8cac7d/solr/solr-ref-guide/src/circuit-breakers.adoc
This is the raw source for that page:
https://raw.githubusercontent.com/wrunderwood/solr/4b93ec27ac7e7b26f3745f90c41268b3fe8cac7d/solr/solr-ref-guide/src/circuit-breakers.adoc
Just some thoughts, and I apologize if you are already well familiar with the issues…
You might give some thought to the specific license you use; “open source” covers a pretty broad spectrum. For example, the technician class curriculum project that I am working on will be licensed CC BY-SA [https://creativecommons.org/licenses/by-sa/4.0/], which will allow other people to use it however they want–even commercially–so long as they credit contributors and share any changes or adaptations according to the same license terms. There are a lot of different licenses which cover different usage scenarios and reserve some combination of your rights; it’s worth doing research because once it’s out there, it can be difficult to change your mind.
If you just want to release it into the wild, that could be all that you need to worry about. If you want to still exert some level of editorial oversight or control, you might look into how successful small open source software projects are administered and come up with a scheme for managing contributions. I’d hate for you to end up having to do more work managing the efforts of others than if you had just written it all yourself.
This is one of the aspects that’s most confusing to me. I need to find someone knowledgeable about this topic to give me some advice.
IANAL, and this is not legal advice, but CC BY means “do whatever you want, just give me credit”. CC BY SA means “give me credit, and release your version under this same license.” BY NC means “do whatever you want other than making money from this, but give me credit.” BY SA NC is “do whatever you want other than making money from this, but give me credit and release your version under this same license.” Note that the NC ones do not actually meet the definition of open source, because the definition does not allow the copyright holder to prohibit particular uses. There are also ND licenses that prohibit derivatives, but that would prevent others from contributing. Again, IANAL; talk to a lawyer if you think it is necessary.
73