Our roadmap involves both business and technology development. Presented here is a high level view of the developer side. There are several fronts that are being worked on simultaneously, and in each of those areas, there is plenty of opportunity for contribution. Furthermore, as the project progresses, the roadmap will of course change, so visit this page every month or so to see what is now behind us and what new terrain lies ahead.
If you are interested in contributing in one or more of these areas, please contact us!
Also, feel free to visit our Investor Roadmap.
Documentation / Tutorials
Formal documentation is of course another constant need. HOPE sits squarely in several sectors:
- It is an end-user application
- It is a platform for which open source and for-profit plugins (receptors) can be developed
- Its implementation is open for developer contribution
As such, there is no "one document fits all" solution -- documentation must be tailored for the specific needs of the loosely defined categories: user, marketeer, and developer.
There is also a constant need for more tutorials, especially short screencasts, and for updating old tutorials, both screencasts and static screenshots.
This involves working with the architecture and implementation of:
- The receptor engine
- Asynchronous processing
- Distributed processing
- The semantic database
- Semantic types "namespacing"
This deserves its own section, even though it is a bullet item under core technologies. The semantic database is currently being built on top of existing RDBMS products. We currently support SQLite and MySQL. Further work in this area includes:
- Support additional RDBMS products
- SQL Server
- Support for NoSQL databases
- Support for graph databases
In addition, we may consider an implementation of the core concepts that does not require relying on an existing third party technology.
The Integrated Development Environment is an essential tool for users to build applets. Work in this are involves:
- Ensuring a clean separation between the IDE and the core technology components
- Improving the user experience when developing HOPE applets:
- Hints / help
- Testing techniques
- Porting to other OS's
- Development of a web-based IDE
- Desktop and mobile web application development
- Resolving architecture issues around server-side receptors
- The HOPE Desktop replacement
We are always looking for new and interesting receptors, especially those that interface with existing data streams.
- Data Streams
- Stock market ticker receptor
- Email receptor (POP & IMAP)
- Social media (Facebook, Twitter, Linked In, etc.)
- News feeds (RSS and non-RSS)
- Friend of a Friend et al.
- Web Ontology Language
- Linked Data (http://linkeddata.org/)
- DBPedia, Freebase, etc.
- Semantic Web
- Natural Language Processing
- 2D / 3D
- HOPE Desktop
- Integrated browser
- Integrated File Explorer
- Fun stuff
- Useful utilities (alarm clocks, todo lists, etc.)
The HOPE "Store"
We are in need of the development of a store from which people can:
- purchase commercial receptors
- download open source receptors
- obtain updates (either automatic or manual)
- semantic types global repository
Versioning is recognized as necessary. Similar to how Ruby gems work, we need the ability for the user to specify specific receptor versions and for the IDE to record these versions automatically. Also, version management of semantic type definitions will most likely be necessary as well.
In particular, the IDE (or underlying engine) must be capable of setting "restore points" so that the user can return to a specific earlier version.
Updates to receptors and global semantic types must be fully documented, and the HOPE store must provide a mechanism for reviewing that documentation.
Last but not least is the area of testing, which presents some unique challenges:
- Development of test jigs in an asynchronous, distributed environment
- Unit testing of receptor behaviors
- Mocking receptor dependencies
- IDE integration testing (desktop and future web app)
Because HOPE applets are 100% componentized, we would also like to offer the service that the end-user could upload their applet configuration to a secure, virtualized "test bed" in which to validate applet behavior with new receptor and semantic type versions. In partnership with the end-user, we would implement unit and integration testing. This will require the development of "universal" testing tools and harnesses.