Hey guys, just read the thread for the first time. I think it makes sense for me to convey the vision for ChiliPeppr so folks understand why an offline version heavily complicates (even undermines) ChiliPeppr's goals.
Here were some core principles embraced in the design of ChiliPeppr:
- ChiliPeppr must enable the community to modify and extend it as a core design philosophy, which means it must be easy and un-intimidating to edit.
- ChiliPeppr is an open source project that will consist of people with day jobs, so it must allow for fast iteration cycles or it will not flourish and if it can't flourish it's not worth doing in the first place.
- The browser is the new operating system that has surpassed any desktop development environment for developing apps so it must be embraced as a core design principle.
- ChiliPeppr will make the developer documentation and developer community be included in the actual user-interface itself, i.e. why you have "fork widget" in the actual UI pulldown menus
Here were some old-style principles that were heavily rejected to try to create a new layer of thinking for the overall design:
- Traditional desktop app
- Packaged release cycles and installers
- Inability to edit the codebase easily
- Inability to find which part of the codebase represents which part of the UI
- Operating system dependent codebase
- Dependency management hell (maven, os-dependency, versioning, etc)
As a result of the core principles, I think it's worth exploring a list of things you would not have if ChiliPeppr supported offline as a main design goal:
1. You would not have workspaces.
This is a massive shift from traditional desktop apps and traditional web apps. I think folks arguing for offline are taking for granted how incredible workspaces are. They give the ability to the entire user community to create any flavor or mashup of widgets they'd like and then have those immediately available to everyone. This empowerment is why ChiliPeppr provides mass flexibility and future-proofing for the community. Getting rid of that via offline actually undermines this fundamental and I think folks asking for offline aren't actually considering this. To get into this mindset required tossing all preconceived notions of what an app is.
2. You would have no Grbl support.
The Grbl workspace was a result of the workspaces concept (which again is very unique on the web and I think other sites will copy). If workspaces weren't so easy to create, you would not have had a new member of the community (Jarret) just jump in on a weekend and fork a Grbl version which was immediately available to the online community. If offline had been the approach from day one there would be no Grbl support because nobody would have stepped in.
3. You would have no forking of widgets.
Any new developer is always loathed to go look at another developer's code. It's painful to try to get your head around how the original developer built stuff. That's why the majority of open source projects get no community involvement. Just look at all the dead projects on Github. For the UI to self-document which code file represents what UI widget is a breakthrough because it helps any new possible developer to immediately see the source code running in a development environment. It's basically like a billboard advertising for each widget saying "help me, i need improvements". The other key on this breakthrough, which can't be taken for granted, is the notion of the "IDE in the cloud" which is JSFiddle. If you had to setup your IDE exactly the way I set mine up, there would be almost no community involvement as folks would just give up really quickly. To achieve this magic combo, you need to be online, not offline. If offline had been a design approach, this whole concept would have been removed and ChiliPeppr would be a miserable piece of software today.
4. You would have no login capability.
Many current features are attached to the cloud login. The webcam server/client requires a login to share your peer-to-peer data connection. More and more new features will also be attached. JScut integration only exists due to the login. An upcoming release of SPJS will allow login from the command line so you no longer have to hunt for whip IP address SPJS is on. Future cloud storage of settings and retrieval of backed up iterations will be available. The ability to pull up a pendant view on your mobile phone will be enhanced due to the login so you don't have to hunt for IP addresses again for SPJS and so your Gcode file can be retrieved via webrtc peer-to-peer data connection.
5. You would have 10% of the feature set you have today.
- Too much wasted time on the packaging of releases.
- Too many features lost due to desktop software.
- Too much developer time wasted on dependency management.
- Too much time wasted on supporting folks who simply didn't upgrade to the latest release (this happens today on SPJS because it's a traditional desktop binary).
- Too much delay to new feature releases.
I am making this statement based on how easy it is to build apps in the browser today vs building traditional release-based apps that are packaged. I have over 20 years of experience doing software apps and I've learned the things that slow you down. Doing version releases and repackaging .zip files and .msi installers is one of those things. Trying to manage dependencies on a large Java project is one of those things. Trying to write one code base that runs on all operating systems is brutal. Those things have all been eliminated by embracing the "browser as the new operating system." The 3D viewer is the center piece of ChiliPeppr. That feature is enormously hard to write in any language, but the state of WebGL and frameworks like Three.js and the amount of community and examples around Three.js changed the game for making this core feature achievable. If ChiliPeppr had taken an approach of desktop or offline, this approach would not have been made, and thus you'd have less feature set because the 100 hours spent on the 3D viewer in Java would have gotten you 10% of what you have today in WebGL. This 10% can be extrapolated to almost every other aspect of ChiliPeppr because packaging everything for an offline release and creating an update cycle would mean of the hours spent on the project too high of a proportion would be wasted on stuff we've all learned can be eliminated from an online app.
6. You would not have as good of a UI because the browser would not have been used.
The ability to use CSS and the state of HTML and Jquery makes the browser a richer UI environment than anything out there today--way beyond JavaFX, way beyond .Net's XAML, and way way beyond QT's widgets or GTK. The webkit engine has billions of dollars invested in it today by Google, Apple, and other massive players. It is the pinnacle of the modern UI today and is the new operating system whether folks like it or not. People take for granted how hard it is to build good UI and for the time spent on ChiliPeppr, the UI is amazing because CSS/HTML and the browser DOM is just truly amazing today.
7. You would not get any of the future features that will change the game.
A major new feature being worked on right now is machine vision for ChiliPeppr. This means you can put two $10 USB microscopes on your Shapeoko and it can now do depth sensing to detect your Z zero from afar, detect the edge of your workpiece, auto-rotate your Gcode to match your workpiece, find fiducials (which include homing your machine via fiducials in your wasteboard rather than using limit switches). This requires OpenCV which is a C/C++ library. This means that to get anywhere with supporting this, it can't be desktop binaries because compiling for every platform out there like Windows 32bit/64bit, Mac OS X, Linux, Raspberry Pi, is a non-starter. Thus it must exist in the cloud. Google Compute Engine is the answer because it's almost free. The OpenCV machine vision engine will run in the cloud. You'll get full access to it. It will change the game for all Gcode sending apps into the future. It will only be possible because ChiliPeppr is an online app.
Here are other future features that require the cloud:
- A 3D library of CNC machines is in the works so that your machine can be viewed inside the 3D viewer as a ghosted out representation so you can see where your spindle is in relation to the overall machine extents. Apps like Othermill have this and ChiliPeppr will get it. Due to the disparate nature of machines out there, this library will constantly be updated and need to be online.
- Firmware version checking and upgrade. The firmware versions of different hardware releases like TinyG are changing constantly. Without being online no checking could occur of cloud variables, thus you'd lose ChiliPeppr telling you a firmware upgrade is available. ChiliPeppr is slated to support avrdude and bossac so that you can simply say "update my firmware" and it downloads the new .hex file and flashes your hardware.
- Pick and place. One of the holy grails of the circuit board makers in the CNC community is a good pick and place system. This requires hardware and software to work in tandem. There's no good standard software today and likewise there's no standard hardware today. To get there we need to iterate a lot as a community. We need machine vision. We need extended feature sets. We need a component library. We need a UI that is simple. We need Eagle BRD import scripts. We are just 5% of the way to a solution. We have to focus on adding code and not focus on being offline or we'll never get there.
- On app store for ChiliPeppr. This will allow folks to better publish their own plugins. You can see an ever-growing list of plugins including Frank's ShuttleXpress jog pendant, or Ben Delarre's GPIO server, or Kevin's TinyG configurator. If ChiliPeppr were offline, the notion of publishing new plugins would be way harder or just wouldn't end up as a built-in feature. Too much time would be spent on the sub-packaging of offline versions of plugins and the update cycle and dependency management of plugins. You'd simply just have to give up on ever having an app store.
- A community wiki list of macros. People still don't know the power of macros and they will get better. An even larger library will help folks do even more. To get there folks need to be able to just click share and it's in the cloud. Offline would remove this notion.
- Laser cutting. The world of laser cutting is still in it's infancy. We need a plugin that allows you to calibrate your laser, or calculate feeds and speeds based on wattage, focal point spot size, which nanometer your laser operates in, and which material you're cutting. This requires its own set of app store plugins, and/or own workspace, and/or even new hardware. To iterate enough code versions to get there requires no blockers in the way like worrying about offline versions, dependency management, packaging, etc.
- 3D printing. There is a new board called TigerShark for 3d printing based on TinyG. There is already a new workspace forked from the TinyG workspace that is gaining new widgets specific to this board. There will be a cloud slicer engine avaialable to all users of the workspace so you don't get stuck with having to figure out what slicer to use. The slicer is os-dependent code thus its easier to just toss into the cloud than worry about packaging desktop versions.
- Smoothieware support (and others). There is no CNC or Gcode sending software that has great support for all popular boards out there. Why? I think if we had a platform that supported all of them, we would gain a better platform for folks to feel compelled to write add-on plugins and widgets because a larger userbase would use or benefit from the add-on. Therefore enabling other hardware to create a workspace, extend the work already done on ChiliPeppr, and move us all forward is paramount. If we focus on offline we lose this because we slow down the release cycle, we make forking harder, etc. It's more important to move forward than to focus on offline.
Open source nature of ChiliPeppr enables somebody in the community to create an offline version.
Now, to comment on the nature of open source. I do think if a certain group of folks want an offline version of ChiliPeppr, that this should be embraced by that group and a new open source project could get created that perhaps turns the online app into a packaged offline app. That group would have to commit to playing the cat and mouse game of removing online features, packaging the app, creating a release cycle, etc. If new online-only features get added to ChiliPeppr, this offline group would just have to get creative on how to hide/remove that feature. I think that's pretty cool if that can be achieved.
I do want to comment though, that for me, I can't ever let the offline version break my thinking or anyone else's thinking that's contributing to the mainline features of ChiliPeppr. For this reason I don't like the idea of an offline app because it could slow down people's thinking with stuff like "oh, but what about the offline version, that would break my feature..." because then we just moved backward in life.
BTW, I haven't published the open source license but I have made statements in other forums that it will follow Linux's license of GNU GPL v2. I will soon publish that in the header or footer of the site somewhere.
On paying for ChiliPeppr
I think if somebody in the community wants to create a paid-for version, then perhaps model it like the Linux community. There was and still is the core linux kernel that is open source, but we got commercial versions like RedHat for enterprise customers that wanted support. I think if we got that with ChiliPeppr it would be awesome.
I, like many contributors, have a day job and having payment for ChiliPeppr would undermine the open source nature of the core project so I think it's best to not have payments come into play for the core project. If any folks want to do payment beyond that then I fully support it and in fact think that could be a huge move forward for the community.
On the Internet and the cloud not going away
The Internet just isn't going to go away. So, for any folks who have a workshop where they haven't run wifi or Internet, what I would ask is that those folks spend the money to do it. ChiliPeppr is free software. If you had to pay for Mach3 you'd be spending real cash. Take that cash and spend it on wiring up your workshop. You'll gain all the advantages of the cloud way beyond ChiliPeppr.
My final thought is, we all have a lot of work to do in the CNC community. We are at the infancy here and I believe we've only scratched 3% of the surface. We need to make sure the least amount of hurdles stand in our way from creating the features we're all craving to be more productive and do more. Let's let our software evolve at the fastest pace possible.