- Octopus, a “tentacular” shield for Arduino and FishinoPosted 4 days ago
- Keychainino: a programmable, playful Key RingPosted 2 weeks ago
- Let’s Build an open source Quadcopter – Part2Posted 3 weeks ago
- Let’s Build an open source Quadcopter – Part1Posted 4 weeks ago
- An open source 3D Scanner made with Raspberry PiPosted 1 month ago
- Open Wheels 2: an all-in-one board to control any of your robotic ProjectsPosted 1 month ago
- GuppY: Fishino becomes NanoPosted 2 months ago
- FISHINO becomes MegaPosted 2 months ago
- Discovering OpenSCAD – part 2: advanced functionsPosted 2 months ago
- How to make an OpenSource Vertical PlotterPosted 2 months ago
Meet the founders! An interview with Circuits.io
With this post we are kicking off an official “Meet the Founders” column to let you get in touch with the best innovators, leaders and startup founders in the field of open and collaborative electronics and hardware. We think that, by putting you in touch with the founders of exciting ventures and creator of successful products you could obtain a great inspiration and be guided in your endeavours.
Today we wanted to present you Circuits.io a company that is trying to revolutionize online, collaborative circuit design.
Circuits.io was founded by Karel Bruneel and Benjamin Schrauwen. Karel is an electrical engineer, holding a PhD in FPGA design tools. He co-founded Dwengo earlier, a non-profit organization focussing on building a microcontroller board and educational material to promote technical skills in high school students. Ben is a machine learning and robotics professor at Ghent University and co-founded Mollom.com before. Circuits.io is currently growing the team and looking for talented engineering with experience in web, EDA and electronics. Why don’t you join?
[Open Electronics] What’s your vision about the advancements and next steps in open source electronic development from your privileged observatory (being both researchers and entrepreneurs)?
[Circuits.io] We strongly believe that electronics design is lagging behind software design for a decade or two and that this is mainly caused by the total lack of design reuse and sharing. Not even the component libraries are shared… that’s just terrible.
That’s why circuits.io totally focuses on finding new ways in which electronic designs and knowledge can be reused. A first and obvious step was to build a design tool with one component database shared by all users, but we also introduced the concept of a module, where a self-contained part of a design (e.g. a power supply or a bluetooth module) can be used in different designs by different users. You can see the module database as a component database, but on a higher abstraction level. A nice thing about modules is that most of the complexity of a design is located inside the modules. Interconnecting modules requires a lot less expertise, so if experts build the right modules on circuits.io, many more designers that don’t need to have advanced electronics skills will be able to build powerful designs by simply interconnecting available modules. This is also made very accessible by building the whole experience directly in the browser, no need to install software. Doing this also allowed us to rethink the usability of electronics design, making it much more accessible.
[Open Electronics] How did the circuits.io idea came to life?
[Circuits.io] While I was writing my Phd, I was involved in a project where me and my colleagues at Dwengo were experimenting with graphical programming in the browser that would allow high-school kids to easily program and build robots. Doing this really was an eye opener for me of what is possible in the browser. Around that time I also started to talk to Ben and we found out that we had very similar ideas on where electronics design should go, so we decided to team up in the beginning of the summer of 2012, …
[Open Electronics] We recently published a post about the challenges of switching from Open source Software development model into developing Open Source Hardware collaboratively. I’m (simone) also involved in the Open Source HW Documentation Jam that is actually focused in understanding better the context. What’s your point of view?
[Circuits.io] We think the git-model (fork, push, pull, merge, …) is the way to go. We believe the real-time collaboration model, like in google docs, is less useful for electronics. The main problem in adopting the git-model for electronics is that nature of the data of a circuit or a layout is just not fit to dump into a git repository, so in our opinion reusing git is not an option.
[Open Electronics] And, how circuits.io is trying to tackle this challenge?
[Circuits.io] We have a solution for this problem and are working on the implementation.
[Open Electronics] There’s a lot of talking about what actually means open source for hardware: licenses, definitions and so on. What’s your point of view on this? How one can decide to license a circuit on Circuits.io? What licenses do you allow?
[Circuits.io] We are not lawyers ;), but the licensing issue for OHW is indeed problematic. There are just a few licenses which really cover open hardware correctly, but these haven’t been “validated” in court yet. We offer almost all commonly used open licenses on circuits.io (CC, TAPR, CERN, MIT, GPL, BSD, LGPL) and leave it to the end-user to decide what to use, but advice for CC, TAPR or CERN.
[Open Electronics] Are you searching for investors or you’re more thinking of bootstrapping your startup?
[Circuits.io] We are largely focussing on building critical technology, but are also talking to investors. An investment would allow us to accelerate, but would also force us to become profitable soon, so we also are keeping the bootstrap route open.
[Open Electronics] What are the challenges you’re facing as a startup? Business model? critical mass?
[Circuits.io] EDA is a relatively mature market, so a lot of functionality is expected before you can start competing with the existing players. We do believe that the classic EDA business model should be re-envisioned and could move to one where the main focal point of revenue is not the software, but the service of getting to a manufactured product.