During this MakerNet phase two, one of the areas we’ve been exploring is a collaborative platform(s) for sharing (and finding) designs of useful items, enabling people anywhere to make them. This includes sharing digital design files, instructions, and all the other information that might be needed to reproduce an item, as well as the ability to adapt and improve designs (version control), and for some authorized groups to tag or certify certain items (for instance, that they meet specific requirements or standards, which is important for safety). We have referred to this concept as “Makepedia”.
In this exploration, we identified Wevolver as a platform that may provide a useful way to document hardware designs and enable collaborative design iteration. Wevolver’s mission is: “to enable anyone, anywhere, to develop hardware that improves lives.” Wevolver was founded by Richard Hulskes and Bram Geenen, and my experience with Wevolver was largely supported by Cameron Norris, Community Connector. They are responding to the “societal need for innovation and intrinsic human drive to create.” They do this by enabling decentralized collaboration on hardware projects for both private teams and open communities. This societal need is inherent in our own work as well, and we’ve been exploring ways to break barriers in hardware development where they are needed most. We have tested their tool these past several months by setting up and publicly sharing one of Field Ready’s more complex projects – the Otoscope.
In this review, I’ll be focusing on my experience, as a non-developer, in setting up and using their platform from October – December 2017. We had identified criteria earlier for digital file-sharing, outlined below. We understood, before this test, that Wevolver did not meet all our desired criteria (no existing platform did); however, their longer-term strategy does factor in more of the criteria. On the criteria that is available today, I provide comments below.
The Wevolver platform is accessible to the public, freely. Anyone can view and download projects listed openly on its site. A viewer does not need to register with the site to do this. However, a user that uploads a project to the site can choose to make the project public or private. If private, a fee may be charged for using their platform. Per their site, “Wevolver is free to use for public and open source projects. When you register you also get a free 60 day trial of our Large plan with up to 20 private projects.”
Wevolver’s software is partially open source. Per their site, “We follow an open-core model where as much of the source code of the Wevolver platform as possible is open source. Wevolver is collaborating with a software development community on its source code.”
Ease of Use
It is easy to view projects on the Wevolver site; however, in searching for a specific project, the only option is to use the web browser’s search function. The site itself does not have search/find capabilities beyond scrolling through the projects. Presentation, however, is beautiful. They do an excellent job of presenting the projects professionally and in a way that is aesthetically intriguing. Below, first, is a screen shot from my PC, and next to it, a screen shot from my phone. As I scroll down, more projects appear.
In regards to viewing the project page, it uses an index and book reader type format. I found it relatively intuitive to navigate the content. To see what I’m referring to, a screen shot of this is below.
Each file folder seen on the left (what I refer to as the index), represents files and pages, which when clicked, will appear in the main section to the right. If a viewer, clicks “Branches” in the index header, s/he will even see if there are pending changes to the project. A nice touch is clear, direct designer attribution and licensing at the top of the main section.
The set-up, or uploading, process for the Otoscope project was initially difficult for me. Unfamiliar with the logic of the offline application and a text editor (Cameron recommended Atom) required to populate the project page, I experienced a steep learning curve. We had scheduled two weeks for uploading all projects, including this one, and the entire process took about four weeks and late nights by all. That said, the Wevolver team, especially Cameron, offered, without a doubt, first-class support. Cameron, an apparent expert with Atom, stepped in and helped format the content so that it was presentable. And I learned from Cameron through this process and began to understand the logic and a bit of the codes. Even with the time zone difference (Uk to PST), Bram and Cameron quickly responded to questions and issues as I raised them.
The process starts with a project folder on the client (my) side. This forms the structure of the index seen on the project web page. It also is what is read by the offline application and Atom. The application takes changes made in the folders and Atom and then it pushes them to the project web page and visa versa. i.e. if another makes changes to the project and synchs those with the web page, then my offline application will pull those changes before pushing new ones. There were some bugs I experienced, like not being able to open the offline application from my PC desktop shortcut and image loading issues.
I do believe that without their support, I wouldn’t have finished by our deadline. In response to such challenges, the Wevolver team has since enabled project documentation functionality also through the browser itself. I have yet to try this new feature. Under the prior process, my recommendation would be to have an in-house person with developer skills who is familiar with such processes or else ensuring Wevolver support will be available. One alternative to this, of course, is scheduling learning time into the uploading process for the person doing it. Or now, utilizing the browser to do the same which Cameron shared is more user-friendly for non-developers.
Flexibility & Customization
Most file formats appear to be able to be uploaded (PNG, JPEG, XLS, CSV, PDF and STL were the ones we used) and links to external documentation or sites are possible as well. While CAD files are possible to upload, a viewer is not able to preview them (Cameron shared that BRD and STEP previews are now also possible). In terms of format and customization of the content on the project page, this may depend on skill level with text editors. Content from the text editor is reflected in the “documentation.md” files listed in the index. For other file types, what I saved in my PC project folders is what appears on the project web page and index.
The basic structure is documentation index on the left, main page on the right – this is not changeable. Besides that, it appears the information shared is highly customizable. For example, how a user may desire to share his/her BOM is flexible. It can be uploaded as a file that is able to be previewed online. It can be a downloadable file. It can be linked to a collaborative cloud file, etc. The data fields are completely up to the user to determine. Of course, this places more responsibility for accuracy and completeness on the user. There are no “forced” rules to ensure the perceived necessary data is shared.
Commenting is currently not possible; however, it is on their road-map for future functionality. This is important for us considering our collaboration approach to hardware development. However, what this functionality should actually look like, we’re still understanding. For example, on most digital design file-sharing and knowledge-sharing sites, there is limited commenting by viewers and makers. Most engagement is one-way – sharing what one has done.
The ability to archive projects is very important. Considering the work involved in uploading and maintaining projects online, it would be expensive (and frustrating) to lose that work because the platform went bankrupt or we desire to use a different platform. Wevolver “allows” archiving in the sense that we maintain ownership of the files (it pulls from our own folders) and the text editor is flexible to our preference (assumed; I imagine some new bugs may occur with an untested editor). Also, projects are able to be cloned or downloaded by guests and then used how they wish. If they clone, they will need the offline application to save and receive updates to the original files. If downloaded as an archive, they will receive all the current files without revision history. (Update: the offline application may no longer be necessary with the online editing functionality recently offered.)
There is the option of downloading, individually, the different files in the project. There does not appear to be a way to download multiple projects at the same time. For example, there is no way to select multiple projects and then choose download. Regardless, some re-work will be necessary if decide to migrate designs to a different “home” as that platform will most likely have its way of doing things.
Yes! In the Wevolver 2 version, version control is available. Per their site, they enable parallel development tracks and their version control “takes care of branching off and merging”. Wevolver makes it possible for everyone to know the latest, concurrent revision of the project. The revision history is also available, with the bonus of annotation for simplifying the search for a particular revision. The screen shot below reflects this.
We have yet to fully explore the collaboration functions and desired our humanitarian item testing engagement to help us understand this feature better. To participate in this testing and provide feedback on the Otoscope in particular, visit the Field Ready Otoscope page on Wevolver.
The Wevolver team is exceptional and already has come a long way in developing a platform for sharing design files and enabling collaboration. They are structured as a public benefit company and have received investment that is clearly going to good use. They are moving quickly along their product roadmap. A bonus has been their support of our mission by sharing the Otoscope project and our work with their wide network.
What does this mean for “Makepedia”?
It gives us insight into desirable content structure for sharing designs and information. Wevolver uses a tailored structure that allows for flexibility in content sharing. Project navigation is handled on the left side of the screen, information is read or seen on the right. Everything else is determined by the project owners and the limitations of the text editors. There are a few pro’s and con’s to this in my mind. I shared a few pro’s earlier, like the ability to show BOMs in different ways with uniquely determined fields. Another is that, in the industry, the range of hardware items is large. There are many different categories and data needs. The flexibility of the Wevolver structure allows for this. Yet I wonder how some level of standardization will enhance their platform offering. For example, a con of too much flexibility is that it may be more difficult to compare hardware options to one-another. For example, say there are two otoscope designs and they both share different information. A viewer will spend more time figuring out which one s/he may wish to build off of. How might industry documentation standards be translated into digital open hardware standards? A platform itself doesn’t need to agree to and “force” such standards. This could be something that the project owners decide to use or not to use, with the platform agnostic to the choice made. This seems to be the direction Wevolver has taken.
We welcome your thoughts on the ideal content structure for sharing design files. Please feel free to share them directly: firstname.lastname@example.org; or review one of our humanitarian items documentation and tell us what you think on the feedback form.
Thank you for reading! Questions and comments are appreciated and welcome.
To explore Wevolver further, see www.wevolver.com and contact Bram Geenen (email@example.com), co-founder of Wevolver.