The way to do it is to find an open-source project which is strategically important to a company, and yet which can't be made proprietary without destroying its strategic value. For example, the reason Android is open-source is because it would be hard to convince a broad base of hardware partners to support it if were closed-source (and now that one particular hardware partner is starting to dominate, it's getting more closed-source). Webkit is open-source because it started as open-source, and yet it is strategically important to Apple, Google, and Opera (well, until the Blink fork, but Blink is also open-source because it was derived from Webkit). Linux is strategically important to IBM, RedHat, etc. because they sell enterprise consulting services; having the source code available gives businesses confidence that they can continue running even if the vendor goes out of business, and yet they still drop a lot of money on consulting services.
It generally does not work to start a company based on open-source principles without also thinking about the strategic implications of who else will use the technology and what incentive they have for keeping it open. For example, LiveJournal was based on open-source principles and developed MogileFS, memcached, Gearman, and LJ itself. The effect of this was that every time they did something wrong, someone would start a clone of LJ and a clump of users would move over. And then Facebook took memcached and used it as a core part of their architecture, and won the whole social networking space.
Whenever anything went wrong with LJ - server issues, PR headaches, unpopular feature decisions - a large clump of users would often very vocally say "I'm leaving", grab the opensource codebase, and start a competitor. Facebook faced all the same hiccups, but users generally stayed with them even when pissed off, because there wasn't the same option of grabbing the codebase and all your friends and opening a competing site. Moreover, it's just demoralizing to see your hard work appropriated by people who hate you and are trying to compete with you. This isn't really about Facebook, it's about DeadJournal and uJournal and Journalfen and all the other competitors.
It's also much harder to convince investors to back you when one of your primary competitive advantages is given away to anyone. I think this was probably the major problem; LJ wasn't really backable as a separate VC-funded entity, and when it was a subsidiary of Six Apart (itself VC-funded) it competed with the mothership for resources and got little attention.
In a world where Android didn't exist as an open source solution, if the value proposition was high enough, there still could have been a chance a closed source license OS could have succeeded. We'll never really know.
Right now though, I'm working on trying to develop a consortium of other like-minded individuals in which we can brainstorm ideas, implement them in open source tools, then distribute them in the various forms -- either VMs, puppet manifests, docker templates, openshift gears, etc. The idea is to lighten the duties for the typical sys admin and make it easier for smaller schools to implement highly tested, rigorous deployments with minimal insight on the actual workings. It's amazing how much academia suffers from large corporations/consulting firms that gouge these smaller schools based solely off the fact that they can because they lack both qualified individuals as well as competitive salary offerings.
Partial proof: https://github.com/mozilla/repositories https://github.com/mozilla-b2g/repositories
(that's 30 _pages_ of github repos, not including the stuff we do that's not on github: http://mxr.mozilla.org/)
Basically, if an open source project is valuable to an entity with money - can be a corporation or a non-profit - then that entity may hire people to work on that open source project. Being open source, the project may not be directly profitable for whoever sponsors the work (the code itself is not being sold, might be support though), but indirect profits or non-monetary effects can be very significant and enough to make paid work make sense. (Of course this is just one kind of way to get paid to work on open source code.)
edit: there is a downside. My job frankly isn't much different than many other software jobs; it just so happens that the output is open source. I still have a boss, we still have company priorities (though I help set them!) and strategic goals, etc. I don't get to just fuck around and work on whatever I want. So you should be careful: if what you want is the latter (work on whatever you want, get paid), you probably need to be someone like Linus. That said, the project I work on is damn cool and my job is better (for me; I don't think jobs are good but rather the tuple <job, employee> can be good) than almost anything else I can imagine.
edit2: I'm unfortunately not listing the company name because there are some real dicks on HN; you can probably figure it out if you're really interested but please don't post it.
I know WordPress has a mixed view here on HN, but that's kind of the point - we're (http://wpengine.com) looking to bring some "outside blood" with experienced with best-practice lower-level, heavy-lifting PHP experience that we can help inject into the WordPress Core project.
Interestingly, a lot of engineers I've spoken to don't want to quit a full time job at a company to work on Open Source.
So, my reverse question is where would you go to find folks who want to work on Open Source.
* Perceived job security, especially developers with mortgages, families, etc. Going from a core-function role within a company to working on OS apparently feels like less job-security.
* Don't want to move from working in office environment to (probably) working from home.
* Project politics and different working relationships of "peers" - not aligned colleagues for same employer.
* Not considered the most financially lucrative engineering positions in terms of performance bonus or career progression
Can you elaborate on this point?
I could do it for you. But I'm not a PHP programmer and don't live in Austin. That's probably why you're having trouble finding people. I could also get together a remote team and manage or work with them for you. It's what I did for my last client (actually, an Austin company as well).
I wish there were some kind of website or book that would answer the question, "Who is getting paid to work on open source, and by whom?"
There is good data for the Linux kernel, for example. On lwn.net you can always see the % contribution of each company. Presumably you could mine the kernel git repo to find out how many people that actually constitutes.
Getting this kind of data for other large/famous projects should be possible.
If anyone has pointers to something like this, please speak up.
EDIT: I guess an important metric would be, "For Company X, what % of code is open source vs. closed source." It would be nice to work at a company that is 100% open or reasonably close, other things being equal (which they aren't, but my point still stands).
EDIT2: I think providing a centralized site that collects these metrics and also allows people to submit them for smaller project/companies, would be awesome and very useful. Possibly even Kickstarter worthy.
When I was closed source, providing support was my downfall. People would do stuff like install other plugins that conflicted with mine, and expected me to fix it. That was very time consuming. Now I give the code away, but charge for the support so I'm compensated proportionally for the time spent fixing that kind of stuff.
I'm also releasing a SaaS version of the product - it's the same thing as the open source code, but obviously the users don't have to install anything or fuss around with servers, and they won't be able to break things [as easily], because they're pasting javascript into their website instead of installing server side code. I'm hoping this will be a huge market.
I did an interview with him a few months ago if you're interested: http://jhackers.net/Kazuho_Oku.html
(come to think of it, every programmer I've interviewed so far on above site works on OSS projects for work to one degree or another)
It's nice working on free software, but I'd really be just as happy if I'd ended up in a different part of the company.
I wasn't a fresh grad; four years and two jobs out of school at that point.
anyway, i got that job by using mule in my previous job, and writing some blog posts explaining it - mainly intended for my co-workers, but i posted them on the net. that, plus providing patches / feedback, led to them offering me a job (and it was a good job in may ways - very smart people, and i learnt a lot).
which is all pretty much what you'd imagine people to say (get involved in a project that has money to pay developers), so nothing very new here....
Are there any resources outside of what's on the site that you would recommend? In particular, I see that there is onsite training but I would love to have more in-depth training material that's in a pdf or ebook type format or even just online.
- The first way is to become a key contributor and maintainer for an open-source project with significant financial backing, and then get co-opted by one of the organizations providing the backing. As an obvious example, a significant Linux contributor or maintainer will have no problem getting a job at dozens of technology companies. In our case, we are constantly scanning the mailing list and irc channel for the most consistently helpful and reliable contributors. If you follow this route, make sure you pick a project you're passionate about and won't mind working on for a long time, focus on being reliable rather than impressing with your technical skills, and make sure to go beyond adding cool features: help other users, improve the documentation, review patches, fix small bugs, etc. I can't emphasize reliability enough. In a really successful project, the maintainers are usually busy and overwhelmed with demands. Be the person they can rely on, consistently, and you will earn their trust.
- The second way is to join a technology company with an open-source team, and be assigned to an open-source project. For example 2 of my co-maintainers joined as employees before the open-source project launched, and were assigned to this team via the normal company process. This will usually get you into a project in its early stages, when it is not yet large or popular enough to hire from the pool of existing contributors. In our case, we now hire almost exclusively out of the project's community.
- The third way is to turn your own project into a source of income. This means either hope that your project becomes popular enough to attract financial backing on its own (also known as "winning the lottery"), or secure funding yourself. Remember that open-source software is like music, writing and web apps: lots of people love doing it, and the barrier to entry is low, which means it's a buyer's market. There simply aren't enough dollars available for everyone to make a living scratching their own itch. Consider finding a job which can accommodates time for side-projects. Make sure your project is its own reward, see how successful it becomes, and adjust your financial expectations as you go. There are sources of funding like Gittip which might make this more feasible - I don't know. Or you could do what I did, and start a business around your project, keep at it until it's successful, find a great CEO to replace you, and finally enjoy your reward as the maintainer of the project you worked so hard to make possible. I'm not sure I would recommend it - it worked, but took me 6 years, most of which with very little time to write code, and an amount of work and stress I would not wish on anyone. But when it works, it's the best :)
I'm always happy to talk about this more if you're interested. You can find my contact in my profile.
Fun gig.
The project was to implement a data integration standard among different construction companies who were competitors so it was actually a tricky job. The chair of the project were Bechtel and they decided it would be open source.
Three years later i had a great journey but i also had to quit. not only was i making good money relative to where i live, but i travelled to some beautiful places and met extraordinary people. Since that was my first job, i was totally spoiled because now i can't accept any job that is less exciting, so i am currently pursuing being independent, which is the only alternative i would accept.
There are corporate open source jobs out there and i recommend that you look for them, but be careful you might get spoiled.
As for how I did it, well, I replied to a job offer looking for Python programmers :)
What types of companies are targeted by your company? I have had thoughts of getting into this space but not sure how companies are willing to go with such a solution versus more established and recognizable solutions (such as Microsoft Dynamics AX, UNIT4, SAP, etc.)
I would love to hear your thoughts on this.
Ours, in bioinformatics: http://intermine.org
For example, d3.js is open source, but the code for PageRank and its related search engine is not. When I was a grad students, I worked on projects funded by NSF and DARPA where the code and data were not released. So it totally depends.
Some professors and grad students care more about releasing software into the public, while others don't care or don't bother writing reliable code.
I'm looking for a topic for a masters thesis/possible job?
In UK, most academic posts will also be on job sites like this one http://www.jobs.ac.uk/.
You can see our job ad from when we were hiring a JS person here:
https://github.com/intermine/intermine.org/blob/master/docs/...
I've worked as a programmer on bioinformatics projects in academia for the last 15 years. Everything has been open source.
Academia doesn't pay as well as the Real World but there are many benefits. As well as being able to work on open source software, the work is usually interesting. Job security has been excellent and I've moved jobs when I've wanted to (5 jobs in 15 years). Everywhere I've worked has had plenty of vacation days, sick days and a good pension plan.
The most useful benefit to me at the moment is flexibility: I mostly work remotely and I choose my hours.
Many bioinformatics jobs don't require prior experience of the field. I started with a computer science degree and no knowledge of biology and learnt the rest on the job.
During the interviews I apologized for the inconveniences of exclusively using and making Free Software. The vegetarian image helped a great deal. What also helped a lot was that I already made the commitments years ago. It would have been a lot harder otherwise : how could you justify applying for a new job and at the same time apply new standards ?
I work as a Ceph developer in the context of OpenStack : very fashionable and easier to get jobs. That also helps a lot.
So, I founded Fogbeam Labs[1], started writing code, eventually recruited a couple of co-founders, wrote more code, networked a lot, pimped the startup shamelessly at every turn, and ...
... TBD.
All joking aside, the end of this story hasn't been written yet. But we're pretty optimistic. We made some great connections at the All Things Open conference in Raleigh last week, and our content marketing strategy has paid off in that a trickle of inbound leads has been coming in. We're also looking at a sort of not-quite-a-pivot-but-something-like-that (call it a "swivel" instead, maybe?) where we're probably going to bump up the prioritization on releasing some SaaS applications built on the fundamental technologies we've been working on.
On a semi-related note, I actually do get paid to work with if not always on Open Source, by virtue of consulting at Open Software Integrators[2]. We specialize in helping companies with deployments of things like Tomcat, JBoss, MongoDB, Hadoop, Neo4J, etc.
That being said, there are many opportunities to work on the projects, albeit a little less "directly". Companies like Red Hat have large teams dedicated to QA, support, etc. Most of them are actively involved in contributing bug fixes, test cases, and directly working with customers. These types of positions do not usually require as much direct experience with the project as the engineering teams do.
And as one commenter already pointed out, we're definitely hiring! http://jobs.redhat.com/
[1] github.com/yui/yui3 [2] github.com/yui/pure [3] github.com/yahoo/mojito
[1] http://www.iq.harvard.edu/ [2] http://openscholar.harvard.edu/
I suggest to watch the first part of Aaron @tenderlove Patterson's closing keynote at Rails Conf 2013[1], that touches upon this topic.