Looking for places to contribute on EdgeX Foundry? There is no lack of areas where technical and non-technical contributors (whether individuals or a small team) can help. This list provides some suggestions and needs to spur your imagination about projects that you and/or your team might find interesting. Get in touch with Keith Steele (keith@iotechsys.com) or Jim White (james_white2@dell.com) if you need assistance in getting on-boarded with the EdgeX Foundry community and are ready to get started!
Technical Projects
Device Service SDKs for alternate languages/platforms: the device service SDK is a tool for generating the device service scaffolding to help connect a device or sensor to EdgeX. Today, the SDK is written in Java and produces device services in Java. We want to offer SDKs in multiple languages (C/C++, Go Lang, Python, etc.) to make it easier for organizations to onboard their devices/sensors to EdgeX in the language of their choice that best meets use case needs. EdgeX is religious in its belief in polyglotism – that is that any micro service can and should be allowed to be written in a programming language (and with tools from that language) that makes most sense to the authors of the micro service. Multiple device service SDKs in various languages can help achieve that goal at the south end of EdgeX.
Device Services: EdgeX is about providing connectivity to devices and sensors. It’s about collecting the data from those sensors/devices and actuating those devices/sensors. In EdgeX, this means providing a device service micro service that provides that connectivity. EdgeX already has some device services with more coming. But if you have a device or sensor that you would like to be able to connect to EdgeX, use the device service SDK (or choose to create it by hand given the EdgeX APIs) to create the device service that makes provisioning and using that device / sensor easy with EdgeX. The term device/sensor should be applied loosely. A device service could also be used to connect another edge platform or application (open source or proprietary) or facilitates ingestion of data from a specific protocol (like OPC-UA, Haystack, etc.).
North Bound Export: EdgeX provides some basic facilities to get device/sensor data to your enterprise or cloud provider. Need to get the EdgeX collected data to a specific cloud provider or enterprise system? Help extend the export services in EdgeX to include other distribution endpoints, transformation engines, filters, etc..
Micro service API documentation generation: today, EdgeX is using RAML to document the APIs of the various micro services. The tools to help generate the RAML from the code are less than perfect. Tools to generate code from RAML (like client stubs) are still pretty nascent. Tools to generate human readable documentation (like RAML2HTML) are helpful, but could always use improvement. Do Swagger or other API documentation sets offer better, open source alternatives? Are there better tools that exist (in support of RAML or other formats)? Can you help pick better API formats, help provide better tooling, and help make them part of the EdgeX CI/build process? Could some tool or tools be used to support multiple API formats simultaneously (example RAML and Swagger)? How can we support message based protocols (MQTT, DDS, etc.) in the future? Your opinion matters with the EdgeX community, but this is an area where the opinion must be backed up with proof. Create a solution that demonstrates how API documentation can be easily generated, easily digested by tools and easily consumed by human users.
Performance Expert: Do you know how to make Java hum? Are you aware of how to optimize the Spring Framework to allow Spring Boot applications to start and load faster? If you have skills to help reduce the footprint of our existing Java micro services, improve the startup time of the micro services, or otherwise optimize the micro services in terms of memory, CPU and speed, we could use your help. Our goal is to eventually provide alternate language micro services that can address performance issues with executables that are best for various use cases and platforms. Today, EdgeX is all Java and help to reduce the EdgeX footprint, throughput, and speed would be very welcome.
Tech Writers
Wiki clean up: Our Wiki documentation was initially create for the Dell Fuse project. It was written by several people over two years. We’d like to have the documentation read more consistently (single-author look and feel) and we would like to make sure it is accurate (many elements have changed in the two years of the Dell Fuse to EdgeX release). If you are a tech writer that is an expert in taking what exists and making it shine, we could use your help.
Getting Started Guides: OK, we are software developers. Sometimes developers can write good documentation and sometimes we are not as clear as we should be. If you are a tech writer and can help us clean up or improve the project’s documentation, we would love to have your contributions. In particular, there are many “Getting Started” guides and examples we would like to have written to ease developers and users into EdgeX properly. IoT can be a complex set of software and hardware. Help us make EdgeX easy to use and understand.
JavaDoc Writers: EdgeX code (most of it) contains Java Doc comments that are used to produce JavaDoc documentation. Think you have both the writing skills and technical skills to improve this documentation? Great! We could use the help. In particular, it would be helpful to make the content of the JavaDocs to read more consistently.
Marketing
Evangelism: Know of an IoT event that EdgeX should be participating in? Are there blog sites that focus on use of open source technology to solve edge/fog deployments? Would you like to sponsor and run an EdgeX hackathon in the future? Help us get the word out on EdgeX.