0. Decide how you want to license codebase and how much you care about post-release adoption.
1. Write enough documentation to understand what the project is and can be used for (i.e. an edited version of what you have already posted)
2. Minimal demo project / app that the can be build so a prospective user can understand the application / library (probably updated example you already have)
3. Clear repeatable build instructions for demo app/ lib etc
4. License and Copyrights clearly stated and in codebase.
5. One or two paragraph guidance on contributing to the project or using the project.
6. Plan on where to announce, announcement msg and follow up so you can monitor interest.
7. If you decide you do care about adoption, plan on some regular but minimal effort after release to write updates/project blogs so folks can see what is happening and encourage interest. *i.e. dont just throw it public, do no marketing or launch effort and expect people to magically find it and adopt it - some sustenance effort will be necessary. If you don’t care, but just want to release it so its out there – then this step is obviously not necessary.
Finally, perhaps, an alternate way to get people interested in Lucidity and demonstrate Lucidity's benefits would be to package up Lucidity and look to contribute new features / functionality that leverage a subset of Lucidity to an existing project that would benefit from those Lucidity's features.
> ... - what do you have to lose by open sourcing it?
That's pretty much my line of thinking as well. It seems like not much.
Thinking about it more, part of what I've wanted to figure out by posting:
1) How much interest is there (so will it be worth my time to do the documentation, etc.)
2) What's the minimum set of tasks I'd need to do in order for it to have some likelihood of getting picked up by others.
3) Is there some clearcut business usecase that I've never considered that someone on HN might bring up.