JSONEditor lets users view, edit and format JSON. Data is displayed side-by-side in a clear, editable tree view or code editor.
Jos is a passionate programmer who enjoys the creative process that programming is. He lives with his family in Rotterdam, the Netherlands.
How did you come up with Mathjs and JSON Editor?
When I first started writing software, I had a lot of ideas which I wanted to try out right away. What resulted was that I started one project after another, none of them ever getting finished—because the number of ideas grew faster than I could build them.
At some point, I got fed up with doing a lot but having nothing materialize, and I wanted to build something "real", something that would be useful for others too. That's when I decided to focus all my efforts into building one math application, Mathjs.
Soon afterwards, I created JSONEditor out of a personal need. I saw it as a temporary solution, and never imagined it to grow this way. I made a conscious decision to work on JSONEditor along with Mathjs in my spare time.
How do you juggle multiple contrasting projects such as Mathjs, JSONEditor & others?
Today, I have created a routine for myself. I set aside some time each week to work on open source projects. I pick one feature from a particular library and work on it until it's finished, before moving on to another one. I never work on multiple features at the same time, because I'm already stretched too thin.
The hardest thing for me to juggle is working on new features, following my own agenda, fixing issues, pull requests, and answering questions from users. Input from the community is not something you can control, neither the subject nor the timing.
While these inputs are extremely valuable and help improve your product, there is sometimes so much input that I find it hard to get back to my agenda. I've created a rule for myself, to manage this—I spend a maximum of 50% of my time on community-driven issues, and I leave the rest for my personal work. This rule works like a charm.
What are the advantages & disadvantages of working on multiple projects at the same time?
There are simply so many interesting things I love to work on! I only wish I could get more hours in one day. :)
Juggling multiple projects means I always have something interesting to work on. If I'm tired of one, I can continue on the other. The disadvantage of this is that your time is split. It can become really hard to balance, as explained in the previous answer.
It's easy to underestimate the amount of work required to maintain a library once the number of users increase. There have been moments where I thought I'd have to drop a project because I simply didn't have the time to maintain them all. I never want to be a limiting factor in the future growth of a library with lots of potential.
How would you describe your problem-solving process?
In short: first understand what you need to solve and why. Then implement a solution incrementally, while continuously checking whether your solution indeed solves the need.
It sounds trivial, but this is actually important: make sure you’re solving real problems for real people. It's easy to forget that what you're building is, ultimately, for the user.
For example, if you're building a dashboard with charts displaying trends of finances, it can be tempting to make it generic and customizable, so users can do "anything" with it. However, this may not be helpful to the user. They might end up feeling overwhelmed with all the options available, clicking around ten times before they gets what they needs. It may be that a less “powerful” dashboard, one more tailored to their needs, is what they're looking for.
How do you understand a user's true needs?
To figure this out, you need to get a deep understanding of the user. That's what differentiates awesome software from tolerable software. For me, it's important to put on my 'user hat' and look at my product with the eyes of a user, again and again and again.
When people come with suggestions, they often figure out a solution. Instead of implementing the solution right away, it helps to ask about the problem you're trying to solve. The better you understand your users, the better products you create. Sometimes, understanding the use case thoroughly might help you come up with an even better solution.
Remember to have a deep understanding of how your product is used. This helps keep it focused and aligned with user needs, while slowing down feature creep.
Try to enforce a fast development cycle, so you can easily try things out and get immediate feedback. You can start by building the simplest thing that 'works' and then add details later.
What advice would you give to developers who are new to open source?
Only work on something you believe in. Don’t do things because “they” say it is important. Don’t do things because you think it’s good for your open source career. Don’t make choices for languages, frameworks, or patterns because it is the mainstream way to do things. You have to believe in what you do and how you do it yourself. From inside. That's what will keep you motivated.
When working for a boss or paying client, it is important to work efficiently, as there is money involved. When working on open source in your own spare time, it is completely up to you, and I think having fun and having a feeling of satisfaction is most important.
So: just play around, try out weird ideas that pop up in your mind, spend as much time as you like on making some piece of code beautiful. Do it just because you enjoy it. And don’t work against deadlines, things are ready when they are ready. Build software that you can be proud of.
What were some obstacles you faced while working for open source?
The biggest obstacle is a lack of time :). So many plans and so little spare time.
I also found it hard to deal with pull requests that implemented ideas contradictory to my own plans. The people behind these pull requests have spent time and effort creating it, and it would be rude to just say "no, thank you."
What I learned is that it helps to start an open dialogue. Take the time to understand what this person is trying to achieve. Then explain what you are trying to achieve. Together, you can discuss whether this new feature fits into your library, or if it's better off as a plugin—or maybe not at all.
It's also difficult to deal with low-quality pull requests. While you can't just say "your pull request is bad", you must also remember not to accept a bad pull request just to get rid of it. Doing this will only require you to maintain it yourself.
What I do is to put on the 'tutor hat' and explain the issues I notice. This gets me into some arguments about why things need to change, but this only hones my skills and knowledge.
Sometimes, the biggest value of a bad pull request is the learning process for both me and the pull-requester. It can mean a lot helping other developers grow.
Another obstacle for me is feeling guilty. I feel responsible for these open source projects, so I feel guilty when I don’t reply quickly to issues, or when I don’t manage to fix all the issues reported.
I’m getting much better at this, though. At first, I tried to reply to all issues within 24 hours. Now, this is more like one week. I give people a quick heads-up to let them know I’ve seen it and will look into it soon.
What really gives me joy is when other people in the community help out by picking up a bug or replying to a question. It’s great to see that other people care too. I’m really happy with any help, small or big, from the community.
How important is testing for your project? What tools do you use to test?
Having tests in place gives you peace of mind, which is huge.
JSONEditor (still) does not have a lot of tests. The library is very visually oriented, which makes it relatively hard to test. This means when someone implements a new feature, I have to do extensive manual testing to make sure there are no regressions. This requires a lot of focus and energy.
Mathjs, on the other hand, is heavily tested. It’s tested both functionally and against all major browsers and node.js. When someone makes a pull request with a new feature and the tests give a green light, I’m totally confident with clicking the merge button and publishing right away.
That is a big thing. I’m really happy with the open source friendly attitude of services such as Travis CI, Circle CI and BrowserStack, which make automated testing possible and accessible for open source developers.
For testing (and for software development in general) I prefer simple, straight-forward, low-level tools and solutions. Advanced techniques can be nifty, but bring in more complexity. The more complex your setup is, the harder it is for someone new (or your future self) to understand what’s going on, and the more complicated the bugs you encounter will be.
How can new open source projects build a supportive community?
The projects I work on depend heavily on me, and I'm not sure if they would continue if I just dropped them. There are many open source projects like this, depending on a single person. It’s one of the risks in open source I currently see. This has an upside: you need a dedicated person who takes ownership to make software successful. Still, I would love to have my open source project not rely on me too much.
I think the most important thing in building a supportive community is to be respectful to each other and have a constructive attitude. I don’t tolerate respect-less input. Often, people simply don’t realize their non-constructive attitude and apologize when you point it out. On GitHub, I often talk to people I don’t know, who ask questions or come with suggestions.
Even though you don’t know each other, it’s important to see the person behind the question. It’s a real person trying to solve a real problem for real people. It helps me see people in the community as if they are my colleagues, a real person sitting next to me. A simple trick I use is to look up someone’s first name and call him or her by his real name while responding.
We are all in the same team, after all. We all want to build awesome software and help our customers with the software we create. In open source, there is no need for competition. You can help each other and everybody wins.
What do you do in your spare time?
I have a wife and two kids, and I love spending time with them. I like to work on my open source projects. I also like to play computer games. I mostly play story-rich games and hardly any multiplayer games. I do find it quite hard to balance work, family and hobbies, though it’s going quite well lately.
Did you ever feel like you were close to burnout? What do you do to prevent/avoid burnout?
Yes, regularly. I’ve been overworked a couple of times. I’ve also had long periods of back-ache and RSI due to stress. I think stress is one of my weak points. I try to compensate by planning ahead and making sure my calendar doesn’t get filled up too much.
Whenever I am under too much stress, my body sends me clear signals in the form of a back ache. When that happens, it’s not enough to restart exercises. I have to pinpoint the cause of the stress as soon as possible.
Depending on the cause, it could be that it’s temporary (like some deadline or so) and I have to push through as soon as possible. It can also be time to work on another project or find another job. In any case, I have to slow down a bit in all aspects of life. Make sure I have enough sleep. What is important to me is not stopping everything, but slowing down a bit. A regular life pattern and the people around me (family, friends, colleagues) keep me on my feet.
We ❤️ open source. Fill out this form to get free, unlimited access to BrowserStack for your project's testing needs.
(Responses are edited for clarity).