The rest of the same paragraph that you skipped is:
> If you want a feature implemented or a bug fixed, fork it and implement it yourself and submit a pull request when you're happy with the implementation.
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back. Not being able to request features for free doesn't make it against the "spirit of open source".
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back
while I agree this is at least one of the points of open source, it's also one of the reasons it's pretty hard to get someone who is either not a developper or doesn't have time to play with the source to turn from the commercial to the open source side. In my experience users out there want something that Just Works, or will be fixed within a reasonable time. If they read something like this, they go all like "wtf is this mentality, I'll just buy something instead"
Paying money for software (open or not) is not something immoral, in fact, to me it is the way it should be for most cases.
Also, Open Source should be important to developers. Aren't you a developer? Then be prepared to pay if you want something that's not implemented already. Not being able to program is the illiteracy of this century.
Not being able to program is the illiteracy of this century.
I'm getting pretty tired of hearing this. It isn't the case at all. Not knowing how to use a computer is `the illiteracy of this century', but claiming not knowing how to program is illiteracy is like claiming not knowing how to play piano makes you tone-deaf.
Completely agree. I AM a developer, and I still would have no idea how to help 90% of the projects that I use as dependencies. Each developer has their own area of expertise, and it is completely unreasonable to expect everyone to be able to fix everything they use without an ungodly amount of effort. Sure, I know how to code, but if my graphics driver has a bug, someone telling me "hey it's open source, why don't you fix it?" seems like a completely disingenuous response to me.
But musical literacy does require that you produce music on some instrument or with your voice, and it is rare that any level of musical training would advance very far without a basic understanding of how to use a piano to pick out some notes for reference. You could decide to learn music without ever learning the piano, but you would have to take great pains to avoid it.
Being able to use a computer but having no understanding of how to program it is like being able to operate a record player. Certainly, some people can do masterful work operating a record player -- to the point of an art. You may even learn to operate it in such a way that you could express your own musical ideas. But learning how to operate a record player does not make you musically literate.
I do not think that everyone needs to be a programmer, but I do think that computer education in our schools needs to at least introduce the basics of programming to every child. Even if they do not program for the rest of their life, it will give them a foundation for solving problems and improve their ability to use software others have written.
I agree with you, actually. I just wanted to cover my bases in the event that there's some composer out there who never played an instrument in their life that I'm unaware of.
> I do not think that everyone needs to be a programmer, but I do think that computer education in our schools needs to at least introduce the basics of programming to every child. Even if they do not program for the rest of their life, it will give them a foundation for solving problems and improve their ability to use software others have written.
Totally agree. I actually got an Arduino starter kit for my little sister's birthday for this very reason. It's over her head at this point, but I remember LEGO Mindstorms being over my head when I was her age, yet still being fascinated with it.
Not being able to program is the illiteracy of this century.
While I agree with this sentiment, I think it's patently false. The vast majority of people have a hard enough time using Word or Excel, let alone being able to understand programming concepts or actually being able to program!
I have a hard time using word because it always tries to fight what I am trying to do. It is a complicated piece of software that requires quite a bit of time investment to actually understand how everything works.
In my experience with my other open sourced stuff on Github, others fixing stuff is very rare. Having issues enabled quickly turns into users demanding fixes and no amount of asking for others to chime in aiding with pull requests actually result in pull requests.
IIRC most pull requests come either out of the blue for something new no one has requested before, or they don't come at all until I explicitly say "I'm not going to fix this" and close the issue.
I've had several bugs fixed in quite a few of my open source projects. Even bugs I've posted on my own projects. And they have only a fraction of the attention yours does.
Why not open the issues up and see if it works out? If anything, you can close them if it's becoming a burden.
In any case, thanks for open-sourcing this project.
Then they can fork it and allow people to post issues on their fork... but this does get me to thinking about how many people even involved in the FOSS world don't understand it very well. Perhaps I am the one wrong here.
I suppose, but then you also need to remember no software is bug free (especially not new software). Maintenance is not a step of software development you can just gloss over.
So the only thing I can think if I were to decide using this software is that I will be happily coding along until something breaks. I'll look for a place to open a bug or issue, and see I can't!? At that point I would just go back to some other properly supported editor.
That's true. But if few more developers start issuing pull requests, then the maintenance team could arise out of that, and project would eventually start to also accept bug reports and feature requests. But in this phase, it's obviously that in this time frame the goal of the main and only developer is to get to the point that he has something that "works for him" and has a solid foundation he likes before making it usable to others.
So yes, it's perfectly in the spirit of open source. And no, it's not (yet) production ready for general (non Go coder) audience.
So the only thing I can think if I were to decide using this software is that I will be happily coding along until something breaks. I'll look for a place to open a bug or issue, and see I can't!? At that point I would just go back to some other properly supported editor.
The benefit of free software (open source plus the freedom to modify and distribute) is that you don't have to do this. You can fix the bug yourself and continue on your merry way. There are many, many stories of companies/people that lost thousands (or sometimes millions) of dollars just because they depended on a piece of proprietary software that became unsupported (for whatever reason) and there was nothing they could do about it.
You could contact the dev and have a discussion with him! If the dev doesn't want it to be a feature in his software, you can post your changes as a plugin/add-on. Effort spent on improving a software rarely goes wasted.
> Effort spent on improving a software rarely goes wasted.
Rarely wasted? Have you seen how many open issues and pull requests on github just languish there forever by unconcerned maintainers? Or projects with a million forks because the maintainer has moved on?
Stating up front that you're not going to even entertain bug reports definitely has an impact on those wishing to improve the software and contribute back. For one, it precludes an entire class of supporters (users who report bugs) from even helping out at all.
For this project in particular in its current state, I don't need people pointing out where it's broken. I know that it's broken and close to useless in fact and that there's a huge list of things to fix, implement or improve.
So if closing up the issues section gets rid of this unneeded negative reinforcement, that's a good thing and working exactly as intended.
It is absolutely your choice to have issues or not and as you describe the current project status it is almost certainly the right choice for the moment.
If you intend to the issues up when you reach another state (e.g. widely usable) then indicating that the not accepting issues is a temporary state would be good. I completely understand not wanting issues raised when you already have dozens of things that you know that you need to do already.
From a user point of view the issues list is something I often look at before even using a project to see the activity, scale of the current problems people are having. I also find it a useful source of answers/workarounds. That doesn't mean that you can't be decisive about what issues you choose to work on (from a user perspective a clear response of "no time to work on this issue, send a PR if you sort it" is better than silence).
If you file the issues yourself, you can show to everyone else that you're working on them. That's exactly the kind of communication ST is lacking. Plus, you'll learn about bugs you didnt encounter, so they can be fixed (by you or others) before you have to hit them yourself.
Give the guy a chance to write a functioning editor first. I'm sure he'll reconsider opening up the issue tracker after the thing is actually useful, and maybe has a few more contributors to share the load.
No one is entitled to anything with open source, not even support or a bug tracker. The author is trying to provide an open source alternative to a closed source product controlled by an uncommunicative company. He deserves support and help, not people telling him what to do.
Try walking a mile on his shoes. Bug triaging is a burdensome task. It is perfectly understandable that, for a one man team working in an incomplete software, his decision is to focus 100% in development of his vision.
Or are you volunteering to do the bug triage part?
You're exactly right. I've heard a lot of developers burn out over the sheer amount of work github generates, let alone the amount of entitlement people feel to your labor once you publish your code. If we want to do social coding, we need to be sociable about it.
> If you want a feature implemented or a bug fixed, fork it and implement it yourself and submit a pull request when you're happy with the implementation.
And this is exactly the point of open source. You have the source, you can change it, or pay someone to change it, you can contribute back. Not being able to request features for free doesn't make it against the "spirit of open source".