The more I think about Kite, the more interesting I find it.  It is not about me being the creator of Kite. It’s about the possibilities that are open for everyone. 

Kite is, first and foremost, a hardware freedom project for Android.  Android is the most prevalent open source platform for phones.  There is no open hardware for Android. Kite aims to be that platform.  That’s the primary reason for the existence of Kite!  

What sort of freedoms are these? Any antenna, any battery, lots of your own hardware you can add, and of course make your own enclosure/case.  We provide Raspberry Pi HAT compatibility – but that’s just a simple board (with a few level converters etc) that anyone can change to adapt to any system.  No restrictions there either.

This immense freedom in hardware makes the software freedoms more than meaningful - it raises the hardware software combination to a level of freedom never attainable before by the masses.

A whole lot of people are sufficiently empowered to do some bits of hardware, courtesy the maker movement.  However, the real problem is in the area of software.  The sort of hardware freedom this project gives has been the territory of OEMs. Phone vendors.  Folks with big pockets. Most of the freedoms of the underlying platforms are suppressed by OEMs to deliver consumer goods; this is not wrong! It’s the nature of their business.  Kite makes those goodies available.  Kite shows you how to mod Android to achieve your goals.  We provide a great starting point so that you can achieve what you want to – without us getting in the way.  That’s what we call, “empowerment”.

Kite begins as a hardware project with a standard configuration – Kite v2.  The hardware configuration of Kite v2 is setup in a way that attracts maximum users at a fair price point for everyone. This is one of the tricky parts of the project.

The backers of the project are the citizens of the “democracy” of Kite. Each one effectively is a “voter”.  Voter for what? The direction of the project. Note that it’s too early to ask/answer questions like, “if I buy ten kits, will I get ten votes” 😉. Thing about this democracy, like any democracy in the world, is that each voter will have a different interest & agenda. 

Even me, the creator of the project, can’t predict how this democracy looks like.  I can bet, though, that's it is going to be quite diverse.  So, before deciding the future direction of the project, we let the community form.  Kickstarter ends successfully.  And lo & behold – here’s the community. The democracy of Kite.

What next? Now, people are free to come up with their own list of what they want us, the creators of the project, to focus on.  This is what we call “feature requests”.  Feature requests can be related to hardware or software.  Let me give you some examples.

Hardware features: 5” 1080p screen, barcode camera, “can I make a tablet with Kite?”, and anything else that you may imagine. There is a large ecosystem of component catering to the mobile, handheld & PDA industries - and it's not only in China. We can tap that as required.

Software features: Can I dual boot linux? How to get <piece_of_hardware_X> working with Kite? Can I have an API to control that camera focus distance from Python? and anything else you may imagine.

How do we act on feature requests? In a reasonably democratic manner.  Let’s tackle the hardware first.  Hardware may involve costs, but not necessarily always.    E.g. “how do I use that 18650 battery with Kite” is likely to come at zero cost. That flexibility is engineered in Kite; it’s a matter of configuration of the fuel gauge chip & the charger. 

That said, most hardware features involve costs.  That’s where the democracy kicks in.  More people interested in the idea is likely to lower the cost of implementing the solution. That’s how hardware works.  The proposer of the hardware puts up an idea or a requirement.  People “upvote”.  Based on the votes, we – the creators of Kite – decide the feasibility & cost structure.  If feasible, the feature request may become a group buy.  All feature requests follow our "Openness" principles.  Boards will be open hardware.  Software could get tricky depending on the exact area.  The camera stack is closed (due to the complexity & NDA stuff) - so that part remains in binary blobs.  

It is important to understand that this is not a scheme to corner all the hardware revenue.  With community development, we expect that our involvement should come down.  But hardware evolves, so we can’t be so sure just yet.  And, not everyone has the skills to do displays & cameras.  With time, folks may develop such skills. That is the hope – but until that utopia is in sight, our involvement as “experts” is required.

Let’s look at software features next.  Same rules apply.  Upvotes. Feasibility.  Software features look deceptively simple at first, but they suck time.  That’s where we exercise care.  We allot time carefully.  The bar for software may be higher, as a result.

That last point is very important.  Many people are asking for Linux.  That’s well understood.  If there’s something that sets the Linux community apart, it is that passion. But like I said – this is not something that I decide.  The community decides the direction.  When the community is willing, the creator kicks in!

Makes sense?