Outline
The context
Industrializing an open source software
Selling a product
Conclusion(s)
The context
Meh
CEO@SysFera
Previously research engineer @INRIA in the GRAAL AVALON
research team (LIP/ENS Lyon)
SysFera
We provide software for the usage and management of HPC IT
infrastructure in a hybrid Cloud mode
12 people located...
References
Where it all began
DIET (Distributed Interactive Engineering Toolbox) created in 2001
Middleware for HPC : How to access a...
The Décrypthon project
Early adopters, guiding us on the path of industrializing research
software
The computing platform ...
Industrializing an
open source
software
The path
May 2008 : Let's create a company !
March 2010 : birth of SysFera
Original idea :
We must secure the IP and struc...
Code is IP
Code is IP
Before creating a company you need to secure the IP
from the inside
from the outside
with the authors
Manage your code's IP
architecture
Code snippets from the Internet?
Third-party libraries?
License?
Any global coherence i...
Manage your code's IP
architecture
Possible solutions:
Antepedia Suite : They’re coming from INRIA and it’s OSS!
{eyes, ha...
Software patent?
Patents?
Publications?
Clone of your technology in the real world?
Define your innovation/process
Study p...
Software patent?
Possible solutions:
{A consulting firm in IP}
{eyes, hands, head, jurist}
Manage the past ...
It WILL be the most time-consuming part.
Check developers’: contract type, lab, institute, faculty, et...
Manage the past ...
Only solution:
Patience, Time and Tenacity
... and the future
Who will contribute?
What about the community?
Will you be able to use that code in any situation?
Who ...
... and the future
Only solution:
Clarity, Perpetuity, Serenity
But code is also
code
But code is also code
DIET comes from a research lab
SYSFERA comes from a research lab
All of use were coming from researc...
Version your stuff
Track every change and revert them
Forget CVS and fully embrace Git
Prefer atomic changes over monster ...
Build your stuff
Tracking bugs takes up half of your time (conservative estimate)
The sooner, the better
You know where th...
Continuous Integration
1. compile manually
2. automate compilation from repository with cron
3. add up unit tests and crap...
Your build system is your
friend
Automates tasks
Good support of parallel jobs (scons out)
Extendable
Easy to learn and us...
Unit Testing
Testing is boring
Humans don’t like boring stuff
However,
it saves time by quickly detecting regression
it he...
Document your code
DIET has nice user and developer guides
The API documentation, however, not so much
Developers hate wri...
Continuous Integration
Automates !
Don't do the annoying stuff
Lots of OSS solutions
We are using Jenkins
Plan things
Plan your development sticking to defined release cycles
Define priorities
Structure your developments through...
Be Agile like a monkey!
Be Agile like a monkey!
Prefer small iterative cycles
Plan, test, document...
... The sooner, the better
Get your toolbox ...
Communicate
With your management
With your sales and marketing department
With your clients
With your community
... And ot...
Get a real marketing guy or
girl (or a hippie)
Or you may end up with such a logo
no comment
Selling a product
Selling a product
To create a company (and sell a product) is an adventure itself.
Nerd -> CEO
Goal
Products must be meant to solve customer pain ...
... but in labs you don't meet a lot of customers...
... and a feat...
Business & Marketing
When should we say no (or not now) to a user/customer?
How to build a road-map?
Nice to have != Nice ...
Technology
Framework or not?
How to choose between complete modification and slight
changes?
Be Agile in every way!
Techno push vs
Market pull
Conclusion(s)
Sad conclusion
Software does not matter
UX and User satisfaction matters
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 ...
Happy Conclusion
Really cool adventure
Developers are artists
Innovation, agility and user satisfaction are the keys to su...
Thanks
Mail :
Twitter :
DIET website :
SysFera website :
SysFera@github :
david.loureiro@sysfera.com
@DavidLoureiroFr
http...
From open source labs to ceo methods and advice by sysfera
Upcoming SlideShare
Loading in …5
×

From open source labs to ceo methods and advice by sysfera

754 views

Published on

From Open Source Labs to CEO_methods and advice by SysFera

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
754
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

From open source labs to ceo methods and advice by sysfera

  1. 1. Outline The context Industrializing an open source software Selling a product Conclusion(s)
  2. 2. The context
  3. 3. Meh CEO@SysFera Previously research engineer @INRIA in the GRAAL AVALON research team (LIP/ENS Lyon)
  4. 4. 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.)
  5. 5. References
  6. 6. 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
  7. 7. 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?
  8. 8. Industrializing an open source software
  9. 9. 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
  10. 10. Code is IP
  11. 11. Code is IP Before creating a company you need to secure the IP from the inside from the outside with the authors
  12. 12. Manage your code's IP architecture Code snippets from the Internet? Third-party libraries? License? Any global coherence in the IP’s perspective?
  13. 13. Manage your code's IP architecture Possible solutions: Antepedia Suite : They’re coming from INRIA and it’s OSS! {eyes, hands, head, jurist}
  14. 14. Software patent? Patents? Publications? Clone of your technology in the real world? Define your innovation/process Study patent claims... VERY accurately.
  15. 15. Software patent? Possible solutions: {A consulting firm in IP} {eyes, hands, head, jurist}
  16. 16. 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!
  17. 17. Manage the past ... Only solution: Patience, Time and Tenacity
  18. 18. ... 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?
  19. 19. ... and the future Only solution: Clarity, Perpetuity, Serenity
  20. 20. But code is also code
  21. 21. 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!
  22. 22. Version your stuff Track every change and revert them Forget CVS and fully embrace Git Prefer atomic changes over monster patches!
  23. 23. Build your stuff Tracking bugs takes up half of your time (conservative estimate) The sooner, the better You know where this is going, right?
  24. 24. 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!
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. Continuous Integration Automates ! Don't do the annoying stuff Lots of OSS solutions We are using Jenkins
  29. 29. 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!
  30. 30. Be Agile like a monkey!
  31. 31. Be Agile like a monkey! Prefer small iterative cycles Plan, test, document... ... The sooner, the better Get your toolbox ready
  32. 32. Communicate With your management With your sales and marketing department With your clients With your community ... And others, through projects or events
  33. 33. Get a real marketing guy or girl (or a hippie) Or you may end up with such a logo no comment
  34. 34. Selling a product
  35. 35. Selling a product To create a company (and sell a product) is an adventure itself. Nerd -> CEO
  36. 36. 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.
  37. 37. 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"
  38. 38. Technology Framework or not? How to choose between complete modification and slight changes? Be Agile in every way!
  39. 39. Techno push vs Market pull
  40. 40. Conclusion(s)
  41. 41. Sad conclusion Software does not matter UX and User satisfaction matters
  42. 42. 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
  43. 43. 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.
  44. 44. 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

×