I've been the sole developer of several startups over the years and still am for some. Some suggestions:
- If there's no unequal investment in the startup (like for example someone putting in a lot of money or more time compared to others) ownership should be split equally amongst the founders. Working remotely is a nonsense argument for getting less equity, not giving everyone the same will most likely end up in conflicts later on.
- Make sure you have your equity on paper and come up with a vesting scheme so no co-founder can walk out with 33% after a couple of months while the others have to carry on for years. (for example unlock 4% every month of work so that you only earned the complete amount after putting in at least 2 years)
- Becoming profitable and/or receiving investments can take a while, does every team member have the runway to work on this long enough to not need any income from it?
- You can't just leave like with a regular job since the future of the startup depends on what you do, keep this in mind. If you are not 100% sure you want to spend the next couple of years on this tell the co-founders beforehand that you will build the MVP and decide once that's done if you want to continue or not. A vesting scheme will make sure you at least get something out of it.
- If you complete the MVP and don't want to continue you can consider selling the MVP to your co-founders at a predefined rate in exchange for your shares. If you do this for a good price and terms and they have the funds for it this might be best for all parties since you are no longer connected to each others as shareholders, they don't have to involve you in new decisions and you don't have to free up time in the future for a company you are no longer involved in otherwise.
- You might want to wait with formalizing the shareholder deeds until a investment comes into play (this all depends on where to company is located and what the laws are of course). Do get stuff signed on paper beforehand though!
- Don't undervalue yourself, in the end YOU are building it, idea's alone are worth nothing.
- Startups are rough, prepare for a lot of fights, failure and lost free time and decide for yourself if you think this startup is worth spending a couple of years of your life on. Keep in mind that most startups fail, my personal experience is that this usually has to do with the dedication of the team doing it.
It's not about being blind to criticism, it's about lies being told about a cool new technology in a thread about a cool project build on top of it. This complete comment thread has been taken over by a discussion about IOTA, about parts of IOTA that are not very relevant to this project, and the authors comments of the project who's here as well get snowed under due to this.
1: By using a ternary number system, the amount of devices and cycles can be reduced significantly. In contrast to two-state devices, multistate devices provide better radix economy with the option for further scaling
3: The wallet is secure and does what it needs to do, no, it's not very pretty or user friendly but it works. A new wallet (Trinity wallet) will be released very soon.
ad 2. From the article: "Let’s begin with the common sense, IOTA’s Tangle is a significant leap forward from blockchain". Why do you believe this subjective superlative when the protocol is still in beta and heavily contested? It's like saying: "Fusion reactors are a significant leap foward", while no production ready fusion reactors exist. You cannot make this claim unless you're willing to attest to the correctness and production-readiness. This seems common sense to me.
ad 2: What is this document? "The Transparency Compendium", "Transparency Report", "Blog post"? All of them are mentioned, but there is no mention whether this is an official statement, or just a sputter of random thoughts by the author. It seems official, but isn't.
ad 2: No mention of CyberCrypt in that article. Extraordinary claims require extraordinary evidence. Also, Occam's Razor. That's what I like about the original bitcoin protocol, it's as simple as necessary, but not simpler.
ad 3: It doesn't need to be pretty or user friendly. The complaints are about people losing their IOTA's and all kind of other complaints. Please address these complaints head-on, instead of just making blanket remarks about user-friendliness.
> 1: By using a ternary number system, the amount of devices and cycles can be reduced significantly.
How does that work? Trying to find information, it looks like it's designed for devices of the future that don't exist; so it's built on assumptions that may be plain wrong.
It would be ideal on trinary hardware, but it can work with a trinary emulator for now. I expect to see a Trinary chip very soon. CfB, one of the core devs of IOTA, founder of NXT and inventor of PoS has a team that has been working on Jinn (trinary cpu's) for the last 6 years.
So they're betting that it's the hardware of the future. And not something like the Mill CPU, which has been in development for much longer and it seems it will be able to execute all the millions pieces of existing software, faster and with less energy.
This isn't solving a problem, it's just making it a little less worse. Proof of Work by mining is just a plain stupid and wasteful idea. Ethereum is already switching to Proof of Stake which is slightly better (but it still gives the power to the biggest holders since you have more influence with more ETH, leading to more market manipulation by mining cartels).
I think a non-blockchain, Tangle based concept like IOTA uses is a way better future, better in terms of scaling (the more users the better it gets), no transaction fees and, maybe best of all, no mining/miners.
Proof of work is better than proof of stake as proof of stake makes it easy for those with the most power to forge transactions rendering it useless to anyone who actually sought out cryptocurrency in the first place. Proof of work is just also very bad.
If you like the concept of scripted 3D modelling check out OpenSCAD. Instead of entering commands you create a script that build your model for you, including the option to use variables, loops and conditions to adapt your model to certain parameters. I use this for creating customisable 3D printable models and it works great if you know the basics.
The concept of OpenSCAD is great, but I think it is in need of some modernization. The last time I modeled something with it I discovered how inconvenient it is to do things like create threaded bolts/nuts... it may just be my inexperience with it, but there don't seem to be straightforward ways of creating basic shapes like helixes.
But it would be great to have a concept where you create a model of a table by creating a cylinder, copy and translate it three times, add a flat cube, connect these 5 pieces, and name them table. Then you would have another (non-)primitive that you can instanciate and maybe have some parameters to change it.
Which is cool, and that's why I like SketchUp. But AFAIK you can't switch to 'text' mode in SketchUp where you can edit the history and rebuild the scene.
It would be very cool if they will be able to do this, I've toyed around a bit with multicopters and know a thing or two about the current state of non-military UAV's, here are my thoughts:
- They use a octocopter; that's great for the payload, plus it adds some redundancy; If a motor fails the others take over to get back safely without crashing. A bad thing about this is that it's a heavy lift, so more battery drain, so it needs a bigger battery == even more drain. I think you can get 30 minutes of flight time at the max out of that, with a lot of heavy batteries.
- Multicopters carrying payloads use powerful electronic motors; You do not want to put a finger near a spinning prop, for safety reasons a UAV within reach of people or animals should always be controlled by a human, what if someone runs up to the package to pick it up and the UAV automatically spins up to return to home?
- Auto landing is possible, but might be dangerous; The current systems (for example ArduPilot) use GPS and acc/baro/gyro/compasses to achieve autonomous flight. It works if your in field without trees around you, but the system can't find the best spot to land for you, so you need to land it by hand for this delivery service, controlled by a pilot over FPV (first person, wireless video connection).
- Experimental FPV ranges over 10 miles are possible, but not fail proof, especially in a non-line of sight environment or while landing (low to the ground).
Hate it to be a nay-sayer, this will have a future but the tech isn't here yet at this moment to accomplish it fully autonomous and safe.
I've created native iOS apps, native Android apps, HTML5 apps and I've used wrappers (Titanium Mobile and PhoneGap) over the last few years and these are my findings:
- Native apps take a lot of time to build, especially when you are a web-developer without in-depth knowledge of the extensive frameworks available to the native platforms.
- Wrappers work, but are not nearly as great and snappy as native apps; They might contain a lot of hard to fix bugs as well and are harder to debug if they tend to crash.
- HTML5 only apps are not available in the market/store so no free advertising, you can't access things like the camera with HTML5 only, you therefore need a wrapper.
My vote goes to native development; Although it's more work and code to write it's much faster and stable if done correctly. You've got more freedom and bugs can be solved. A native app just feels right, where a HTML5 only app won't give you the best user experience you can get, no matter how much time you put into it. If you need a flexible, big, cross-platform app without a lot of budget to build at least 2 native apps a HTML5 app with wrapper would be a decent option, but for anything else (especially the more simple apps with just 2 or 3 different views) you should go with native.
I'm curious in how you put Titanium next to PhoneGap (Disclaimer: I may be reading too much into that, or not understanding your meaning - 2nd language etc.).
My experience with Titanium is that you code in js or Alloy, then when building and deploying, you get native code, with native elements and everything.
Comparing it to PhoneGap, which purely runs in a slowish WebView isn't quite fair I think. Or has your experience been different?
You are absolutely right: It's been a while since I last used Titanium. At the time you had to use a crappy/buggy UI to compile your app, with random bugs ocuring all the time, not being able to build once you've upgraded to a newer version due to backwards incompatible changes and more weird incompatibility bugs with other versions of XCode, and so on. I hated the experience since I couldn't rely on being able to building my app and Objective C library support wasn't available at the time or didn't work very well. I quitted using Titanium once they switched from their own buggy UI to Eclipse for building, my code was backwards incompatible, the UI couldn't compile to older versions of Titanium, I had enough. It's true, it has better performance as say a Phonegap, but it did have some weird layout issues from time to time which were hard to fix. Overall I think it's a nice product for creating an app without learning Objective C but I won't use it for a clients app any more, too unreliable.
Oh, and yes, it is 'cross-platform', except for the fact that there are so many things not working on Android (either bugs or non supported in the API for Android) that you need a seperate build for android to make it reasonably useful.
This is al based on my experience with Titanium Mobile from around 2 years ago, so it might be better now.
I think you're right to make this distinction. Titanium doesn't belong in the 'wrappers' family and would be better grouped with other 'cross-platform native' solutions like Xamarin [1], perhaps a 4th category in parent's list.
Titanium is still not quite the same as Xamarin. Xamarin cross-compiles to fully native code from my understanding. Titanium, on the other hand, has JavaScript-to-native bindings i.e. a TiView is a JavaScript object which proxies UIView on iOS.
All business logic is still running in JavaScript. In fact, Titanium spins up a V8 engine just to run your app. This may be fine for the most simple apps, but if you need to kick off a long running operation to a background thread, for example, you're in for some gymnastics.
I'd rather have Grand Central Dispatch, CoreGraphics, CoreAnimation, etc. all at my disposal. Using Titanium felt very restrictive. Their API is a one-size-fits-all between iOS/Android/etc. As soon as you want to step out of that least common denomination, you've got to write native modules. Which, if the people on your team don't know native development, can be a problem.
Have you got experience with Titanium? How is it? I've had a few clients inquire about mobile applications as of late and I'd like to start exploring options for me as a web developer.
There's a slight learning curve, but it's overall very nice to work with. Been making a living from it for a year now, so I'm rather comfortable with it.
You have to get in a kind of different mindset than with HTML, where you use div's for everything - here you create windows and views - but shouldn't take more than a couple days to get dangerous with it :)
There's a few quirks though - differences between iOS/Android for a small number of things, when coding, which can take up a lot of your time to troubleshoot.
An example of such an issue can be on Android, an imageView which you've applied rotation to, suddenly appears to be not rotated, if you put a backgroundColor on it as well as rounded corners. The fix here could be to use a regular view instead, and use a backgroundImage. Thankfully those kinds of weird things aren't as plentyful any longer, the company behind, Appcelerator, are in my experience pretty helpful and fast with bugfixes.
You can also access the camera on iOS using HTML5, a bit buggy though: https://github.com/daraosn/Cordova-CanvasCamera, anyways I also second you, native development is always better, imo.
you can't access things like the camera with HTML5 only
Just a small point of clarification, you can access the camera on Android using the Camera API. You can access accelerometers / gyroscopes and location in both Android and iOS.
- If there's no unequal investment in the startup (like for example someone putting in a lot of money or more time compared to others) ownership should be split equally amongst the founders. Working remotely is a nonsense argument for getting less equity, not giving everyone the same will most likely end up in conflicts later on.
- Make sure you have your equity on paper and come up with a vesting scheme so no co-founder can walk out with 33% after a couple of months while the others have to carry on for years. (for example unlock 4% every month of work so that you only earned the complete amount after putting in at least 2 years)
- Becoming profitable and/or receiving investments can take a while, does every team member have the runway to work on this long enough to not need any income from it?
- You can't just leave like with a regular job since the future of the startup depends on what you do, keep this in mind. If you are not 100% sure you want to spend the next couple of years on this tell the co-founders beforehand that you will build the MVP and decide once that's done if you want to continue or not. A vesting scheme will make sure you at least get something out of it.
- If you complete the MVP and don't want to continue you can consider selling the MVP to your co-founders at a predefined rate in exchange for your shares. If you do this for a good price and terms and they have the funds for it this might be best for all parties since you are no longer connected to each others as shareholders, they don't have to involve you in new decisions and you don't have to free up time in the future for a company you are no longer involved in otherwise.
- You might want to wait with formalizing the shareholder deeds until a investment comes into play (this all depends on where to company is located and what the laws are of course). Do get stuff signed on paper beforehand though!
- Don't undervalue yourself, in the end YOU are building it, idea's alone are worth nothing.
- Startups are rough, prepare for a lot of fights, failure and lost free time and decide for yourself if you think this startup is worth spending a couple of years of your life on. Keep in mind that most startups fail, my personal experience is that this usually has to do with the dedication of the team doing it.
Good luck!