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.

2. Outline
The context
Industrializing an open source software
Selling a product
Conclusion(s)

3. The context

4. Meh
CEO@SysFera
Previously research engineer @INRIA in the GRAAL AVALON
research team (LIP/ENS Lyon)

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.)

6. References

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?

9. Industrializing an
open source
software

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

11. Code is IP

12. Code is IP
Before creating a company you need to secure the IP
from the inside
from the outside
with the authors

13. Manage your code's IP
architecture
Code snippets from the Internet?
Third-party libraries?
License?
Any global coherence in the IP’s perspective?

14. Manage your code's IP
architecture
Possible solutions:
Antepedia Suite : They’re coming from INRIA and it’s OSS!
{eyes, hands, head, jurist}

15. Software patent?
Patents?
Publications?
Clone of your technology in the real world?
Define your innovation/process
Study patent claims... VERY accurately.

16. Software patent?
Possible solutions:
{A consulting firm in IP}
{eyes, hands, head, jurist}

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

21. But code is also
code

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

29. Continuous Integration
Automates !
Don't do the annoying stuff
Lots of OSS solutions
We are using Jenkins

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!

31. Be Agile like a monkey!

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

35. Selling a product

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"

39. Technology
Framework or not?
How to choose between complete modification and slight
changes?
Be Agile in every way!

40. Techno push vs
Market pull

41. Conclusion(s)

42. Sad conclusion
Software does not matter
UX and User satisfaction matters

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.

45. Thanks
Mail :
Twitter :
DIET website :
SysFera website :
SysFera@github :
david.loureiro@sysfera.com
@DavidLoureiroFr
http://graal.ens-lyon.fr/DIET
http://www.sysfera.com
http://sysfera.github.com