This document outlines the process of industrializing an open source software and selling it as a product. It discusses securing the intellectual property of the code, improving development practices through version control, continuous integration, testing and documentation. It also covers challenges of determining customer needs when no existing market exists, balancing innovation and technical capabilities with market demands, and the importance of user satisfaction over technical features alone. The conclusion reflects on how research labs can foster innovation and how 13 jobs have been created by building a company around code originally developed through academic research.
5. SysFera
We provide software for the usage and management of HPC IT
infrastructure in a hybrid Cloud mode
12 people located close to the INSA campus (the weirdos doing
pixel art on the windows? That's us.)
7. Where it all began
DIET (Distributed Interactive Engineering Toolbox) created in 2001
Middleware for HPC : How to access an application on a distant
server in a ASPSaaS fashion
Leading implementation of the OGF’s GridRPC standard
8. The Décrypthon project
Early adopters, guiding us on the path of industrializing research
software
The computing platform of the Téléthon : provide a simple to use
grid platform for biologists
Sponsors: AFM, IBM, CNRS
2007: DIET replaces proprietary middleware (o/)
Has been up and running 24/7/365 between 2007 and 2011
Wait... what if we create a company to do that for others?
10. The path
May 2008 : Let's create a company !
March 2010 : birth of SysFera
Original idea :
We must secure the IP and structure the development process
Building up a commercial offer around DIET while
staying true to DIET's OSS roots
17. Manage the past ...
It WILL be the most time-consuming part.
Check developers’: contract type, lab, institute, faculty, etc.
What part of the IP do they produce?
Who owns the code?
What business model for what business plan?
Most of the time authors don’t know anything about that
Above all: be patient!
18. Manage the past ...
Only solution:
Patience, Time and Tenacity
19. ... and the future
Who will contribute?
What about the community?
Will you be able to use that code in any situation?
Who will lead the project? What’s the road map?
How will you manage the code? (Client/Research)-driven commits?
20. ... and the future
Only solution:
Clarity, Perpetuity, Serenity
22. But code is also code
DIET comes from a research lab
SYSFERA comes from a research lab
All of use were coming from research labs
We needed tools and methodology to get the job done, clean and
fast
So we didn’t follow the (easy) (evil) path of proprietary software!
23. Version your stuff
Track every change and revert them
Forget CVS and fully embrace Git
Prefer atomic changes over monster patches!
24. Build your stuff
Tracking bugs takes up half of your time (conservative estimate)
The sooner, the better
You know where this is going, right?
25. Continuous Integration
1. compile manually
2. automate compilation from repository with cron
3. add up unit tests and crappy mails when compilation fails
4. add quality checks
5. now install a CI server with shiny graphics
6. make developers who break builds bring pastries the next
morning!
26. Your build system is your
friend
Automates tasks
Good support of parallel jobs (scons out)
Extendable
Easy to learn and use (autotools out)
Multi-platform
We are using CMake + make/ninja
27. Unit Testing
Testing is boring
Humans don’t like boring stuff
However,
it saves time by quickly detecting regression
it helps detecting dead code
We are using Boost Unit Tests Framework
28. Document your code
DIET has nice user and developer guides
The API documentation, however, not so much
Developers hate writing anything else than code
(to the coders here: you know it’s true)
We are using Doxygen
30. Plan things
Plan your development sticking to defined release cycles
Define priorities
Structure your developments through projects
Choose your preferred development method (something agile!)
Involve your community in the debugging!
32. Be Agile like a monkey!
Prefer small iterative cycles
Plan, test, document...
... The sooner, the better
Get your toolbox ready
33. Communicate
With your management
With your sales and marketing department
With your clients
With your community
... And others, through projects or events
34. Get a real marketing guy or
girl (or a hippie)
Or you may end up with such a logo
no comment
36. Selling a product
To create a company (and sell a product) is an adventure itself.
Nerd -> CEO
37. Goal
Products must be meant to solve customer pain ...
... but in labs you don't meet a lot of customers...
... and a feature for a user is not what we may think it is.
38. Business & Marketing
When should we say no (or not now) to a user/customer?
How to build a road-map?
Nice to have != Nice to buy
Innovation can lead to new markets ...
... And unknown application fields!
How to know the customer needs when there is no existing
market?
Being too innovative can be a hard problem -> evangelism/"too
much"
43. But being
innovative is the
key to our
success
It's hard, but that's the good way
And research labs are the best place to find innovation
To be here tomorrow: don't fight the change, accompagny it
44. Happy Conclusion
Really cool adventure
Developers are artists
Innovation, agility and user satisfaction are the keys to success
It's a pleasure to see customers happy with your code
I'm proud to say that 13 people are now working thanks to code
developed by researchers from INRIA, CNRS, etc.