3 ms·

Firstly, congrats on an interesting project with clearly a lot of thought and time investment. At end of article you request feedback on should you open source

by ptrott2017 7y ago

Firstly, congrats on an interesting project with clearly a lot of thought and time investment. At end of article you request feedback on should you open source - in that respect: There is clearly some interest in this area e.g. DS-PITON project (See https://bit.ly/35Eq35R https://bit.ly/35Eq35R) or the Jive project for java (https://cse.buffalo.edu/jive/ https://cse.buffalo.edu/jive/). Another would be Glamours Toolkit for Pharo Smalltalk (https://gtoolkit.com/ https://gtoolkit.com/) - though it has a larger scope. If you do not have time or funds to continue it in its current form and you do not have any 3rd party at this point interested in sponsoring development in some form, and you cannot see how to leverage it in the future - what do you have to lose by open sourcing it? At worst - it languishes, and no one uses it but it will give you a referenceable open source project for your CV that may help attract work in this or a related area. At best, the project sees adoption and opens new opportunities for you. Given the quality on display in the articles and videos I would expect the project to get some interest especially amongst IDE and program visualization communities. If you do decide to open source the project be careful on licensing choice (to encourage adoption in a manner you want) and copyright notices to ensure you are associated with it. Do expect to have to invest a little time in documentation and code clean up before making it available - but think of that as future advertising for your own capabilities. Good luck

westoncb 7y ago
Thanks for the feedback ptrott. > ... - 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.
- ptrott2017 7y ago
  re: min set of tasks - Obvious list: 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. Whatever you decide, Good luck.

westoncb 7y ago

Thanks for the feedback ptrott. > ... - 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.

ptrott2017 7y ago
re: min set of tasks - Obvious list: 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. Whatever you decide, Good luck.