Ask HN: How do technical non-developers help with open source projects?
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.
92 comments
[ 3.6 ms ] story [ 145 ms ] threadI 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.
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?
IMHO, very rarely. At such a small startup, a founder or co-founder is going to be the effective product manager.
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.
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
http://words.steveklabnik.com/how-to-be-an-open-source-garde...
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!
Finding the boring things that other people don't do is exactly the most valuable thing you can do for any open-source project.
("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.
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.
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.
[1] http://www.dezeen.com/2014/11/09/christian-boer-dyslexie-typ...
That's fascinating, I didn't know that was a thing. Could you point out any good resources for learning about it?
[1] - http://midonet.org
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.
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.
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...
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.
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.
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
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.
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.