3 ms·

Thanks, that's interesting 'cos I have been thinking of adding import/export to GitHub via Markdown, so that website content isn't locked into Pyxxi. I'm not s

by pyxxi 9y ago

Thanks, that's interesting 'cos I have been thinking of adding import/export to GitHub via Markdown, so that website content isn't locked into Pyxxi. I'm not sure how much of the tool itself I could open source (I've never done that) but I could at least make the client-side search and lists open source, I think, so that web developers could generate their clients' sites without using Pyxxi at all if they needed to. Perhaps they would then only need to use it if they wanted to redesign a site or generate new style sheets. Plus, as you say, their clients could use Pyxxi to edit their site. Especially, as they might not want to do that in Markdown. Do you think that's feasible or would it be better to open source the entire tool?

stephenr 9y ago
I can't speak for everyone obviously, and the pure-SaaS model is definitely popular at the moment, so I'd imagine there is still a market without open sourcing the whole thing. Having said that, I still think open sourcing it will be a net positive for you. Regardless of whatever unique client-side logic your product handles, there are numerous other static-site generators available, that are open source (heck, I'm writing one myself). In this scenario, I believe that being closed, and a service (as opposed to say a closed source, but self-hosted tool) can lose you some potential customers. I don't think being open (and thus self-hostable) will lose you any actual paying customers - those who are able and willing to self-host it are probably unlikely to have paid for a closed service in such an active (in terms of competing products/projects) niche. > I'm not sure how much of the tool itself I could open source (I've never done that) Regarding this specifically, the key thing here is going to be what (if any) libraries/frameworks you're using. Assuming you're not using any commercial libraries, it's probably mostly about making sure the various licences of the libraries are compatible with whatever license you choose to use.
- pyxxi 9y ago
  Thanks. That's really helpful, and interesting what you're saying about self-hosting customers not being willing to pay anyway. I hadn't really thought about it like that. Caroline

by pyxxi 9y ago

stephenr 9y ago

I can't speak for everyone obviously, and the pure-SaaS model is definitely popular at the moment, so I'd imagine there is still a market without open sourcing the whole thing. Having said that, I still think open sourcing it will be a net positive for you. Regardless of whatever unique client-side logic your product handles, there are numerous other static-site generators available, that are open source (heck, I'm writing one myself). In this scenario, I believe that being closed, and a service (as opposed to say a closed source, but self-hosted tool) can lose you some potential customers. I don't think being open (and thus self-hostable) will lose you any actual paying customers - those who are able and willing to self-host it are probably unlikely to have paid for a closed service in such an active (in terms of competing products/projects) niche. > I'm not sure how much of the tool itself I could open source (I've never done that) Regarding this specifically, the key thing here is going to be what (if any) libraries/frameworks you're using. Assuming you're not using any commercial libraries, it's probably mostly about making sure the various licences of the libraries are compatible with whatever license you choose to use.

pyxxi 9y ago
Thanks. That's really helpful, and interesting what you're saying about self-hosting customers not being willing to pay anyway. I hadn't really thought about it like that. Caroline