Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do technical non-developers help with open source projects?
216 points by thomk on April 1, 2015 | hide | past | favorite | 88 comments
I used to code for a living but decided that I enjoy being a technical writer and PM much, much more.

Things I enjoy:

  * Writing detailed functional specifications.
  * Creating wireframes & mockups.
  * Creating flowcharts, BPMN docs & graphs to explain a project.
  * Planning Poker, Creating sprints.
  * Discussing technical issues with developers.
  * Simplifying technical issues for customers.
  * Learning about new technologies.
  * Explaining new technology to customers.
My question is; Is there a need for someone like me in any open source projects and if so, how do I contribute?



With your skillset, you could be doing invaluable work by writing documentation.

The world is full of good Free software that is essentially orphaned, because the documentation is practically useless. Many moribund projects could be revitalised with little more than a concise description of what the software does, why you might choose it over the alternatives, and how to get started.

Other projects suffer from dreadfully myopic documentation, with a wiki full of detailed descriptions of weird minutiae, but little that would be of use to newcomers. Few developers can write well, and even fewer have the insight to view their project from an outsider's perspective.


I have a similar skillset to OP, and I was brought on board to write/improve the documentation for http://www.fluentd.org/

I'm now unable to devote nearly as much time to the project as before, so there's definitely a need in the project right now. The tool is used by AWS, Google Cloud Platform, LINE, Nintendo and others, so it's something that would have wide reach right away.


What is the pay range for someone who does "non-technical" work like writing technical documentations?


Not sure, but I have heard that the tech writers at Red Hat are compensated very handsomely.

It all depends on how much the org values the docs.


Documentation often gets cited as the main 'semi-techncal' thing to do for an open-source project.

However, I disagree with the point that moribund projects could be revitalised this way. If the people writing the code have little interest in explaining to other people like themselves how to use it then IMHO writing additional text for less involved people is not going to be very impactful.

Your second point about myopic docs is spot on, though. A human-readable summary can be invaluable but it involves getting your head around what already exists first -- that requires some will from the developers in the first place.


I actually ran into this issue with the `argus` network flow generator/processor project, run "by one dude." As a non-developer, but a user, I spent time grinding away at understanding it, mostly as a hobby, and wound up realizing that the "one dude" set his bar pretty high at what he expected of his users' skill sets. I can sincerely appreciate that, but that bar should be lowered so that folks can at least use the software effectively without pissing off the entire mailing list :D

I did just as stated here; lowered the bar for non-developers by producing "on boarding" documentation that takes you from no-to-go in about 30 minutes, massaging my inane questions and failures in mailing list etiquette into an accessible wiki doc (accessible at nsmwiki.org for anyone who is specifically interested).

I take pride in it and it even sits on my resume.


Accessibility, accessibility, accessibility.

Are there

- Link skips

- Dyslexia-friendly typography (no justification, no hyphens, preferably fonts with distinct glyphs)

- A colour scheme useable and legible to the huge population of colour-blind people

- Screenreader-friendly HTML

- Closed caption for video - or just transcripts

A lot of fancy-pants projects are absolutely amateurish when it comes to this, and it only really gets their attention, when their JavaScript-only project is penalized by Google's search ranking.


As someone with (mild) dyslexia I didn't even realise there were people out there making friendly typography so I had a look around, e.g. dyslexie font [1] is a pretty cool read.

[1] http://www.dezeen.com/2014/11/09/christian-boer-dyslexie-typ...


Yeah, I employ a "Dyslexia" button on my text-heavy blogs that replaces the typeface with OpenDyslexic. Definitely check it out if you don't know about it.


> Dyslexia-friendly typography (no justification, no hyphens, preferably fonts with distinct glyphs)

That's fascinating, I didn't know that was a thing. Could you point out any good resources for learning about it?


On this, I've seen job postings on HN asking for all these crazy advanced front-end skills that don't have alt-text for their image-text company logo.


Yes! Thank you. Accessibility is much easier if you plan for it from the start and it's very important to have accessible content.


To add that list: - alternative formats text/media - ARIA and semantics for complex js heavy apps.


I work at DuckDuckGo. Our most popular open source project is DuckDuckHack: http://duckduckhack.com/ Developers leverage code, APIs, wikis, etc. to answer searches (across a broad range of topics) in few or zero clicks. What we call, "Instant Answers."

The nature of the project only works well with the involvement of non-developers in that the best Instant Answers are made by subject-matter experts across a variety of fields. Suggesting ideas, finding great sources, and the overall experience of the IA are all better if coming from someone who really wants to improve searches for that topic. https://duck.co/help/community/contributing

Let me know if you're interested in getting involved--any time :)


Are you only looking for non-dev contributors or anything at all? I'm looking for projects to start working on in the OS community currently!


Both! We're really in need of some additional folks with commit bits, if you're interested in getting involved on the technical side. This page will help you find the best place to start but please let me know if I can help: http://duckduckhack.com/


Awesome! I'll take a look later tonight. If I have questions how can I get a hold of you? IRC?


Something I haven't seen mentioned yet: For a developer to become involved with a new project requires some substantial cognitive overhead to learn what files matter, the terminology and basic flow of data through the codebase, etc. There may be interest in having someone with your skillset create "Introduction to Hacking Foo" presentations. For example, if someone offered to tell me the main components of how django works in an easily accessible style with plenty of helpful visual accompaniments, I'd be thrilled. While I can figure those things out, that figuring takes time/reading/effort and anything that could potentially reduce that effort is just great IMO

If your content is good enough and you're passionate about such an idea, I could see a series of these introduction videos/slides/blog posts being a really popular series


Hi there! I know the Joomla project could definitely use some help like that...if you're interested I would send this same message you've written here to the CMS Google Group: https://groups.google.com/forum/#!forum/joomla-dev-cms

Development is entirely community driven (which is both a pro and a con) but at the same time it would be nice to have a strong PM hand helping to guide things again (we had a great person from the Netherlands during some of the early years of the project, Wilco Jansen, but since he bowed out of the role several years back I feel we've been missing that direction he was able to provide).

I would definitely look forward to having you contribute to Joomla if it seems like something you would find interesting!


Very much so! I'd love some help writing/documenting/explaining to people a lot of the work I've done behind Cayley (http://github.com/google/cayley). I can explain it very well one-on-one or to a developer but my writing/explaining/diagramming gets a little esoteric for the people at large. Even planning/prioritizing some things would be useful.

So if graph databases strike you as cool new technologies and you'd like to learn more, check it out and feel free to drop me a line personally at barak (at) cayley.io


Absolutely! I like Drupal's approach: https://www.drupal.org/contribute/documentation

I feel like OpenBazaar is doing a good job of engaging people like yourself to help out: https://github.com/OpenBazaar/OpenBazaar/wiki

Good documentation/specs are essential to speeding up development of a product and something I believe the community is learning to prioritize appropriately.


Most open source project lack documentation, and those that have documentation need more examples, proof of concepts, use cases, etc. It helps if the open source project has a non-technical way to show it off. Take a look at http://gist.neo4j.org/ for example.


Charles here, Community Manager at Sourcegraph (https://sourcegraph.com/). I'm not a developer.

Working with a developer community as a non-dev has taught me a lot. Earlier this year we started an open-source hacker meetup to give authors the chance to come talk about their projects at our office in SF.

To build this program, I help identify authors of open-source projects and invite them to speak at our meetups. While I don't code, I look for the most passionate contributors and try to give them a place to share what it's like maintaining, marketing, and building large projects. These talks are recorded and posted to YouTube where other programmers can hear lessons and challenges from their experience. Example here: https://youtu.be/ScUIlbHnxGI

In essence, open-source projects suffer from a lack of awareness and rely on manual exposure. If you can help open-source projects market themselves, find new contributors, and simplify their message, like nowarninglabel talked about with OpenBazzar, then they have a better chance of being picked up by the community.


I'm a non developer working on the MySQL team.

One of the ways that I try to help is by collecting feedback from our community of users and passing it back to the developers.

Some examples:

http://www.tocker.ca/2015/01/05/what-defaults-would-you-like...

http://www.tocker.ca/2015/02/24/proposal-to-change-additiona...


Have a look at the About[1] page of Michael Kerrisk.

His work on the man-pages project eventually led him to write a very highly rated book "The Linux Programming Interface".

http://man7.org/mtk/index.html


This blog post by Steve Klabnik would be a great start. He talks specifically about managing the issues section of an open source project (Rails).

http://words.steveklabnik.com/how-to-be-an-open-source-garde...


It's not exactly the same as open source, but the Assembly (http://assembly.com) community is a great way to get involved in building products. The community builds businesses together, and everyone shares ownership based on what they've contributed. (also, it's all open sourced under AGPL).

You can jump in on products doing all sorts of things from mockups, to docs, to technical writing, etc. And you can always start your own product too. :)

Here's an example of a product that needs help with mockups of a technical process: https://assembly.com/runbook/bounties/281

[disclosure: I work at Assembly -- happy to answer any questions: austin@assembly.com]


https://assembly.com/secret-society/assets bears a... striking resemblance... to a certain enterprise linux company's existing logo. Do you have any sort of review process in place for this sort of thing (esp. considering these projects are intended to make money)?


Wow - I totally didn't notice that.

If we receive a formal complaint about something the community is doing, we'll usually jump in and try to address it – and in a case like this I'll reach out to that team and let them know nicely that they should be creating their own brand identity.

Thank you for pointing this out.


We would love that kind of help at GitLab. Creating mockups for the functionality that we're accepting merge/pull requests for is very welcome. For a list see http://feedback.gitlab.com/forums/176466-general/status/7964...


Yes! Most Open Source projects were started by coders. Many coders (certainly not all, but many) are either bad at, or bored by, the stuff you've mentioned.

Documentation is often the Achilles heel of Open Source software, so having that ability (specifically "explaining new technology to customers" and "simplifying technical issues for customers") is incredibly valuable.

UI is also often weak and bolted on over time, to a degree almost never seen in well-funded proprietary software. So having wireframe/mockup sessions with OSS projects to sort out their UI weaknesses and maybe consolidate UI elements and make it more coherent to non-technical users would be of immeasurable value.

I say all of these things with the experience provided by the Open Source projects I work on (Webmin/Virtualmin/Cloudmin/Usermin), which have about a million users...but, our UI kinda stinks in a lot of ways especially because it has accreted rather than been designed, our documentation always trails the project (less so for Virtualmin and Cloudmin since we have some money for these projects as they are also commercial, but still a problem), and we never have nearly enough hands to help resolve those problems.

While there are Open Source projects that are insular and closed off (and many that don't want to be might look like they are, just due to not having anyone welcoming and marshaling volunteers, but they probably still want help), most will welcome your input as long as it is well-meaning and exhibits some desire to learn and teach. If you spend a week with almost any Open Source project and don't see areas that need some attention in the areas you've mentioned, I'd be surprised. And, spending a week (or so) with a project is probably the minimum you need to get an idea about the culture and to know where your input would be welcomed.

In short: Do it. There is need for anyone willing to help on most big and small Open Source projects. You'll learn a lot, get a great addition to your resume, and you'll probably make some new weird friends. Most OSS projects won't beg for help, even if they need it desperately...but, it doesn't mean they won't be happy to see you. They're making Open Source software because they want people to use it (usually), so, when you use it and especially when you help make it better, you're doing them a favor, and most will take it that way, even if you aren't super productive at the start.


The biggest contribution that I can think of is spending quality time distilling the true value of a project into succinct, easy to understand, practical language and then (as a technical former-coder) building clear startup / path to use instructions.

Failing that - stand up the code base and help with the README?

I'd also second the gardening / community management effort. It's very important but I wouldn't get too general - keep up your technical / code chops so you can still truly distill things across all the audiences you need.


As others have said, your skillset is very valuable for all sorts of things. For example as a community manager, or as a documentation writer.

I would love to get your help with writing documentation for the Phusion Passenger application server. We're currently overhauling our documentation (https://github.com/phusion/passenger_library). But as a developer who has been working on this project for years, I feel that it's getting increasingly hard for me to understand how my users think. I've become "too good" if you can call it that, so sometimes I struggle to understand what problems users would have, or what they wouldn't understand. Your skillset would help a lot here!

Please contact me at hongli@phusion.nl if you're interested.


As a new-comer to open source projects recently, I found it was hard to get a handle on the 'roles' in a project. I was used to working on corporate, in-house technology projects where there are plenty of non-technical activities to perform (PM, Business Analyst, End-User testing/training, Governance, etc) - but it isn't obvious how those apply to most open-source projects, or even if they are required at all.

I found this link pretty useful to breakdown the activities and roles: http://oss-watch.ac.uk/resources/rolesinopensource

Like everyone else will say...first involvement is a bit nerve-wracking (How will people respond? Can I make a decent contribution? Will I look like a total noob?), but you'll only feel that way once.


Hyperboria / Project Meshnet are definitely in need of technical writing :)

We've been building a routing protocol (cjdns) and accompanying software for desktops, servers, phones, and home routers.

> Cjdns implements an encrypted IPv6 network using public-key cryptography for address allocation and a distributed hash table for routing. This provides near-zero-configuration networking, and prevents many of the security and scalability issues that plague existing networks.

I'm larsg in #cjdns on EFnet IRC in case you wanna hear more.


There's a lot you can do.

* Writing (doc, blog posts, ...)

* Evangelization (answer questions on IRC/Mailing-lists, help your entourage to start using it, go on live conferences, give talks, ...)

* Testing. Test everything in each new release and give the authors a good bug report when needed. Test the tool on multiple OSs, using multiple versions of a lib, test the different drivers, different dbs, etc. Test the installation procedure and the user features.

* Triaging issues in a bug tracker. What's really a bug, what isn't? What's a major blocker for users? What's a luxury nice-to-have feature? What's too old and not relevant anymore?

You can start doing all this, without actually needing any permission or access to anything. I'd suggest you just let the active members of the community know you exist (they usually hang out on an IRC chan or something like that). That's not even required, if you're shy don't say anything and start working.

As you get more and more active, you're going to be naturally contacted by someone active in the project and from here, you'll usually be given more "official" responsibilities.


I run a project called ioquake3 that has been out for almost a decade and we are in desperate needs of more technical folks to help spec out and plan development for the most boring parts of the framework we need to remain relevant in 2015.

Finding the boring things that other people don't do is exactly the most valuable thing you can do for any open-source project.


As the maintainer of a very small project (probably only 1000 users at its peak), a non-technical person would have been able to help me a lot. Because it was a one-person only affair, I had only so much time. I probably spent half of it writing and updating documentation, and building and testing installs. I ended up having very little time to code and since there were features that I absolutely needed for me, I often just jammed them in as best I could. Just having time to concentrate only on code would have helped me a lot. Also, it might sound strange, but if you want a project to gain traction outside of your little world you need marketing. I would have loved to have someone who could write a blog post or two explaining why the project was different than all of the other similar ones around. Doubling or trebling the user base may have attracted another programmer to help with the technical side. The website I built essentially contained only the documentation and while I feel happy with the quality of that documentation, it absolutely lacked anything that would attract new users. Building a screencast showing the killer features would also have been incredibly useful. It was all on my TODO list, but I just lacked time to do it because I barely had time to code the features I wanted.

As you mention, user interface spikes would have been fantastic and saved me huge amounts of time in experimentation.

The thing on your list which I personally would not have found useful Planning Poker. I actually did make sprints and wrote stories and even tracked my velocity. But in the end, you wind up doing demand-based work. Like I said, I wrote the system for me and there were just things I needed done. Those things took top priority no matter what. And with a lack of time, I very rarely got off that list. Even in a large project, I don't think you are going to get much different: coders are in it for scratching their own itch. They will self-prioritise their work and there won't be too much difficulty coordinating it.


For many projects, the single biggest hurdle to success/adoption is good, understandable documentation. Many (perhaps most) open source projects have technical capabilities far in excess of their usable docs.

("Read the whole wiki and then the whole discussion forum to understand" is a huge hurdle for new users.)


> ("Read the whole wiki and then the whole discussion forum to understand" is a huge hurdle for new users.)

Look, all you had to do was search for the forums for the the feature that you don't know the name of because it's not properly documented! I don't see the problem here.

Seriously though, documentation is a big deal. Both the "getting started" intro stuff, and the gritty details of more advanced features.


We have someone non-technical helping us in the https://github.com/angular-ui/bootstrap/ - he helps us triage issues, putting labels and helping get the reporter of issues to be more clear about the information or helping issuers of pull requests get tests in the pull request before it gets reviewed, which helps us developers of the project save time when reviewing the issues or pull requests.

Sprint planning isn't as critical in open source - it is more important to get things done right than to confine progress to sprints. Open source is hard, and core developers of projects can use all of the help they can get.


IMHO the most important non-technical thing for Open Source is evangelism. Talking them up on wikis, encouraging your employer to use them, helping answer questions on open forums... Relative to commercial projects, technical resources aren't the limiting factor.


If you want to get into:

  * Discussing technical issues with developers.
  * Learning about new technologies.
Check out http://www.codetriage.com. It will also help give you the tools you'll need to:

  * Explain new technology to customers.
  * Simplify technical issues for customers.
Pick a few open source tools that your company uses like http://www.codetriage.com/rails/rails and start reading issues. Eventually you'll learn enough to start helping out.


I'm a contributor on the Akka.NET project (http://getakka.net) and one of the things we made that has really helped people understand the framework was a Bootcamp (https://github.com/petabridge/akka-bootcamp).

Sure, there is a lot of code in the Bootcamp, but most of it is clearly explaining concepts and helping developers understand what is really going on, with no jargon.

Anything you can do like that is a MASSIVE help to an OSS project.


Organize the artwork... There is something that always gets in the way of game development in the open source world, and its the artwork assets. Someone just needs to be on top of this component -- coordinating the art from artists contributions, putting it into the project in a way that makes sense, dealing with the requests from developers to format the art a certain way, etc.

Open Source games usually don't hit the sweet spot until someone does this - alas its not always the sexiest part of the project although, it does become the sexiest part of the project pretty fast, eventually.


Yes. These are very important skills you have to make any open source project successful. I know a few developers (including me) who do not love to write functional specs or sometimes even updating a read me, but its necessary.

When I am designing a solution and processes, I need the freedom to do so. When it comes to writing code and tests, updating docs, etc - I absolutely want to be "managed" because self-induced-management is more effort. Even a person who just tracks the process and reminds us "you are not doing this right" is very useful from my perspective.


http://www.weekendhacker.net 8000 developers and designers helping each other out on projects. It's free and very OS friendly.


Docs, testing, but triaging, community wrangling (IRC), web presence maintenance, etc.

There are many ways that open source projects can benefit the help of a non developer. In fact, it is often what projects need the most!


I'm also a technical product manager and have struggled with this question too.

I have also wondered the same thing in the startup context: is there a good role for me in a <10 person startup, <5 person startup?


It depends how far you want to take the definition of what you do away from 'traditional' PM. At a ~10 person company chances are there are a lot of things that need doing around interfacing with users/customers, identifying beta testers, following up, triaging product feedback, writing great docs and content, writing sample code and SDKs, etc. Sometimes one of the founders does it, but as the company grows, that kind of day-to-day is hard for a founder to stay on top of if they have other areas of focus too.

It depends a lot on the kind of project the company is building, of course. A developer platform vs a consumer app will have a vastly different need for such things. I work at a 10 person developer-focused startup and as an ex-PM with engineering chops, I jump between building the product itself, working on developer-facing stuff, and randomly helping out. I definitely wouldn't call myself a product manager at the moment, though -- if you really want that as your job title then you probably need a slightly larger company where you can take the reins on product from the CEO, while the CEO switches to focusing on developing the company itself.


> is there a good role for me in a <10 person startup, <5 person startup?

IMHO, very rarely. At such a small startup, a founder or co-founder is going to be the effective product manager.


What your describing is essentially a business analyst, albeit a technically minded in whilst not being a developer. I consider myself of the same ilk and I think the best thing you can contribute is input and UX/UI design, sanity checking of ideas, feedback from users etc.

The facilitation role between users and developers is so much more than 'documentation' which alot of the comments in this thread seem to suggest.

I suggest contacting a few of the projects listed here, or any you find on GitHub you'd like to contribute to and just offer to help.


You need to find open source projects that suit your interest and you have a genuine passion in seeing them succeed. Look beyond the highly successful ones, and look for projects that have a reasonable community + momentum but are not very famous. There is a lot to be done for such projects

Try https://github.com/explore

Plug: Checkout our project https://github.com/frappe/erpnext


It's not directly answering your situation but I really hope that one day the open source movement will move beyond software and for that we need non-technical people from almost every profession.

I hope the leading product in almost every market category is open source and developed at least partially by volunteers.

Open source beer, where small brewers collaberate with breweries all updating the recipe in github?

Open source mac and cheese showing up on your grocer's shelf?

Open source farm equipment?


An open source maintainer here (https://www.fluentd.org) We can always use your help for our docs -> https://docs.fluentd.org and https://github.com/fluent/fluentd-docs


There is definitely a need with documentation and even style guides and such. I've seen a bunch of pull requests that are merely just edits to grammar and such.

There are also projects like 500lines (https://github.com/aosabook/500lines) where it's a book and you can help out with all types of editorial-type tasks.


One of my projects is pretty technical. It takes a while for people to understand why it is useful. If it's something that interests you, I'd love some help!

The project: https://github.com/egonSchiele/contracts.ruby


I'm currently a software dev student looking to get involved in the OS community, but I'm having trouble getting into a community (or getting the hang of contributing).

I'm willing to do technical stuff or non technical stuff, so does anyone have advice on finding an organization or project to look into?


As a non-coder, I run some software fuzzing and report the findings to the owners.

With my gear I couldn't spend more than an hour a day setting up tests, but processing the results can take up more time. I've found over 100 bugs in 6 months and it has been fun so far.


If you're into healthcare compliance you can certainly checkout our docs repos (simply filter by docs) http://catalyzeio.github.io/

We're always looking for edits/feedback!


Stack of pull requests coming your way :-)

(I was having some bad dreams, and apparently proofreading healthcare documents was what I needed to shake it. Thanks!)


To start with, you could write useful and helpful Readme front pages for a lot of the projects on GitHub :) Sounds like you could even write reviews on your own blog/guest blog sites for various OS technologies and projects out there.


I think there are a ton of projects out there in need of such help. MidoNet[1] is definitely one of them, DM me if you want to talk about some areas where we need help.

[1] - http://midonet.org


It sounds like you can be an amazing developer evangelist.A lot of technical startups (like mine :) ) are looking for someone with your skill set - writing technical blogs, demos, speaking at conferences, meeting with customers, etc.


Don't underestimate the value of great testers and reports of reproducible bugs.


> "Is there a need for someone like me in any open source projects and if so, how do I contribute?"

This is an excellent question. I doubt that anyone is going to turn you away but there are some things you should probably consider. I'm drawing this from my experience with MirageOS [1] and OCaml-related projects I've been involved with.

1. Why are you doing this?

After you've figured out what you care about you should still ask yourself why. Is it CV points? New experiences? Specific project goal? To stretch yourself? Accolades?

If you can be upfront with yourself about what you're hoping to get from contributing then it makes it a little easier to frame what it is that you can offer. As I said above, no-one's going to deny a new contributor but having a flaky contributor is also frustrating. Most projects won't have any kind of 'onboarding' process so knowing why you want to do this at all will help you create your own.

In my case, I can see how a new method of building software (with unikernels) could be transformational. I also want to know that I'm helping to promote the creation of better software for distributed systems. There's a specific use-case I want to be able to highlight too (see point 2).

2. What do you actually care about?

This matters more than you might think. If you're only peripherally interested in a project it'll be difficult to remain motivated, especially if you already have a full-time job. This is more than buying into a project's wider goals (assuming it even has any stated goals) but more about what would actually drive you to continue contributing. It's somewhat related to the above point but a little more specific.

Do you like writing docs? How about blog posts or giving talks? Or doing tests? Triaging bugs? Helping users with issues? Organising stuff (community/devs)? Small project or a large one? Move fast or be considered?

Can you match any of these up with gaps you see in the project?

From my point of view, I want to work towards distributed systems that empower users [2] and I can see how parts of the project can get me there [3]. I wanted to write more (personally), I care about good organisational practices/structures/communication and onboarding new people. Those are the things I tend to think about and it's led to me coordinating fortnightly calls, curating a set of Pioneer Projects and writing a lot more.

3. How will you build credibility?

Since you're not contributing code, it's almost inevitable that you'll end up in bike-shed territory (though even code has plenty of bike-shedding). Everyone has an opinion so why would anyone listen to yours?

I think this is why 'documentation' (inc tutorials) gets touted as the first, semi-technical way to get involved with a project. It's rarely threatening to the existing team and provides immediate value. Many of the other things you mention in your list provide long-term value but they need to welcomed. Again, no-one will state that they don't need these things but that doesn't mean that any offering will be accepted. If you're willing to believe that customers can't always articulate what they really want, then the same applies to any open-source project :)

I don't have a pithy answer for this. I think it just takes consistent behaviour over time. Be reasonable and try and back up any claims but don't be afraid to stand firm.

4. Just start!

All of the above points may seem cautionary but it's best to just get involved. Open source projects can be pretty awesome and there's nowhere else where I've been able to be as transparent about what I'm working on. There's probably a useful blog post in this comment so I may write my thoughts up properly some day (as opposed to this brain dump).

[1] http://openmirage.org

[2] http://nymote.org/blog/2013/introducing-nymote/

[3] http://amirchaudhry.com/brewing-miso-to-serve-nymote/


Your skill set sounds very relevant to the work we do. We are not open source, but do operate a free educational tool for teachers. Please email api[a]engrade.com as we would love to discuss.


This is just an awesome page! Thanks everyone for sharing! I was thinking about doing non dev open source and was really doubting that that exists. I search exactly what is described :)


If you know some natural language other then English, you can help in internationalization of OS projects. Translation of documentation, error messages, interface etc.


Um. YES, YES, YES, YES.

I have a list of small to microscopic projects that need this kind of thing. I am totally a Linux nerd, that's not great for lots of end users.


What kinds of projects are you most interested in contributing to? What kinds of real world problems are you hoping to help solve?


Pretty much all projects can benefit from these kinds of skills. I'm a community manager and technical writer, and I make non-code contributions to open source projects. My process is something like this:

1) Find an open source thing that I use or think is interesting. This has included OpenStreetMap, LocalWiki, MediaWiki, an interactive map project at my former university, a tool my hacker/makerspace has built for itself, an educational website about open source, a tool made by the local Code for America brigade, etc. The important part is just that I like the thing.

2) Get in contact with the people - join the mailing list, IRC channel, forum, meetups, or whatever they use to communicate; look at the bug tracker and blog. Start learning about how the people work and what they're working on, and start asking and answering small questions, pretty much making friends with them in a low-key way. At this point you can probably tell whether they're reasonable people to talk to - if they're unfriendly or non-responsive, abandon ship.

3) Ask for suggestions for what to work on, and find tasks for yourself based on your expertise. Things will come up as needing improvement, and you can propose solutions to the group and start getting them done. For me, this can involve recognizing and filing bugs about user experience issues, improving website copy, writing marketing materials like social media posts and blog posts, organizing documentation, identifying holes in documentation that people have overlooked, and so on. This kind of non-technical work usually requires getting some amount of buy-in and trust from project collaborators, which is why step 2 is important.

4) Yay, you are now contributing useful things to a cool project.

I've written a little more about this as part of one of the projects I volunteer with, OpenHatch (https://openhatch.org/), an organization that helps people get involved with open source: http://blog.openhatch.org/2013/how-i-found-an-open-source-pr... + http://mergestories.com/s/improving-a-project-homepage/. The second post is from Merge Stories, our collection of posts where people explain how they made an open source contribution, to help give newcomers a realistic picture of what contributing looks like: http://mergestories.com/

This is also a helpful article: http://blog.smartbear.com/programming/14-ways-to-contribute-... - a list of ways to contribute to open source that aren't just writing a pile of code.


Did you over time develop yourself from being in a technical/developing position into a technical/management position?


Thanks for the question.

Actually what I did was quit my job at Ford as a developer to do freelance work. I realized that when I was speaking to my own clients I really enjoyed talking about their projects and documenting what was said in a meeting.

Often I would turn-around full functional specifications the same day as the meeting.

I was programming off of those specs and quickly realized that all of the "fun stuff" was already figured out and I was just typing in code, so I started hiring out the programming work.

Developers have often told me that my functional specs are some of the most organized and clear they have ever worked from and it keeps the back and forth communication to an absolute minimum.

This is the waterfall model of software development (http://en.wikipedia.org/wiki/Waterfall_model) and it has helped me earn a living for years. I have built a business around it and don't even have a website for myself.

So yes over time I transitioned myself from being a developer to whatever I am now, but I really, really enjoy it.

I always tell customers "Software is difficult to change, word documents are easy (and cheaper) to change".


> I was programming off of those specs and quickly realized that all of the "fun stuff" was already figured out and I was just typing in code, so I started hiring out the programming work.

Yeah, that's pretty much what I figured.

As far as your status goes, in my book you can't easily transfer that to opensource projects: You do need to go through a bit of the programming work yourself, again, to see how things work in order to get to that same position you fill with respect to business prospects.

At this point I'd say: team up with a few opensource-interested developers and form your own project, from scratch.


If you're technical enough... unit tests.


Have you tried a product like Assembly?


This describes so much what I do and like. Your list is really useful for me. Many thanks!


Proof read our website: emberui.com and submit patches in the documentation repo :)


Put a screenshot of key functionality in the README. I love repos that have this.


first rule of open source: if you use it, you talk about it.


Consider me new to your philosophy. What other key rules should be considered known to the community?


thanks for asking this question, enjoying reading through the responses and may even get in touch with you OP as you sound similar to me.


Please do.


testing! Most open source projects really fall apart when you push them to the edge cases.


Yes! Especially if you know the folks and with respect to helping with documentation and onboarding. I'm technical, but my role in a fairly large, well known open source project was strictly non-technical. Best summed up as: "other". What was interesting is that my role wasn't only product-y in nature (product is my professional calling card). It also included project management, sales (I explain what sales means in the context of open source below), and bd. Ironically, contrary to my advice to you about documentation, I did not focus much of my energies there as an individual contributor, that was already being done already and we worked with customers to improve that. However, onboarding new users is a big challenge for many projects, and I do think the need is there.

Some background: At the time, the project was created and maintained by a very smart technical maestro / team which included a small core team of 1-2 developers. There is/was a large 3rd party ecosystem with shims and plugins into every known framework/language.

This open source framework that I speak of has achieved product / market fit in my view. But like many activities, it was clear that while that value was being created (problem / solution fit, product / market fit), it was hard to make the leap to capturing this value (sustainable business model so it doesn't need to rely on external funding).

My contribution can best be summarized as product management, with heavy emphasis on customer development, standard product management (but less emphasis on product roadmap work, since the technical creator did most of this), lean canvas/ business model work, business plan, working with lawyers, sales and bd work. I relied heavily on my own product / pricing experience and Steve Blank's / Lean Startup approach to figure out some key questions for customer development "get out of the building" type work: e.g. to make this project sustainable on its own accord, is there revenue we can get in the form of support? Because the project has growing traction across the world, I was able to speak with several potential customers who were using the project heavily in their engineering organizations, and learn about their additional problems they have.This then informed the paid "support" solution we proposed. In many cases, customers were satisfied with the free open source version, and we gave them support as well.

One of the most satisfying things was working with early prospects on defining what it meant to "sell an open source product"... the "capture value" part I spoke of above. This had unique challenges because we wanted all deliverables to customers to go back to open source, which we achieved successfully.

Apologies for the long post. tl;dr: yes you can help, especially if you know the folks. I think you're on the right track. If you'd like to learn more details and if I can help you think through any parallels or questions to your own work, feel free to ping me. I'd be happy to help. Email contact is in my profile.


Planning Poker?


Vicky is going away to college in Springtown, but will live in an off-campus apartment in Livingston. The two locations are 2 inches apart on a map of the area; the actual distance is 34 miles. What scale does the map use?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: